GSA Government-wide Section 508 Accessibility Program

Accessibility Resources for Developers and Authors

If you’re an author or developer of electronic documents, software applications, web content, operating systems, accessibility platforms, assistive technology, mobile environments, and modern development frameworks, you need to understand how the Revised 508 Standards (36 C.F.R. Part 1194) apply to your work.

The resources on this page will help you:

  • Find developer-oriented accessibility training;
  • Understand how the Revised 508 Standards apply to electronic content, systems, platforms, and frameworks;
  • Follow Federal Accessibility Community of Practice (ACOP) best practices;
  • Review and prioritize W3C, WCAG, and ARIA authoring best practices;
  • Use automated tools, manual testing, and assistive technology-based testing;
  • Examine best practices for mobile applications and web environments; and
  • Implement popular development frameworks.

The following best practices are supported by peer review and consensus among the participants in the U.S. Federal Government Authoring and Developer Transition Working Group. A single resource is listed only when the group could not identify multiple resources. Inclusion in this document does not imply endorsement by the authors, or the Federal government, and does not mean that other equally valid or useful resources do not exist. To suggest a resource be added, please email GSA at

Understanding Conformance Requirements
Authoring Tool Requirements
Accessibility Training for Developers
Web Accessibility Training
Developing Accessible Web Content
Other References


The Revised 508 Standards incorporate by reference the WCAG 2.0 Level AA Success Criteria, and apply the WCAG 2.0 Level AA success criteria and conformance requirements to both web and non-web electronic content.

Chapter 2 of the Revised 508 Standards specifies which electronic content must be accessible (scoping). Apply the technical requirements based on content type.  The scoping requirements for electronic content (Section E205) apply to non-web electronic documents regardless of format (e.g., Microsoft Office, Portable Document Format, and HTML Web pages).  Other scoping provisions apply to non-web software (e.g., spreadsheet or video conferencing applications), and native mobile apps. There is no distinction between “web pages” and “non-web” content because the same accessibility needs exist for all electronic content.

The Revised 508 Standards include specific requirements for authoring tools (see Section 504). Authoring tools include not only word processors, but any tools used to develop web pages or applications, as well as the Integrated Development Environments (IDE) used by developers for software development.

If your agency has never used the harmonized test methods published by the Federal CIO Council’s Accessibility Community of Practice (ACOP), you may have to significantly revise your policies and procedures to implement and verify conformance to the Revised 508 Standards. The transition will be easier for agencies already using these or similarly comprehensive test methods which already incorporate WCAG 2.0 Level AA. The revised standards also now clarify which electronic documents must conform to the new technical requirements.

Having trouble getting support for IT accessibility? Here are some ideas that may help:

Understanding Conformance Requirements  

As an author or developer, you should assess the extent to which your work conforms to WCAG 2.0 Level AA.

  • A page that fails to meet even one of the 38 applicable WCAG success criteria does not conform to the standards.
  • A set of pages in a sequence, e.g., identifying, selecting, and paying for a ticket to a public event, does not conform if any of those steps fails to conform fully.

In some situations, you can comply with the Revised 508 Standards by providing a conforming alternate version of content.  However, you should be aware that Sections E101.2E205 and E207 of the Revised 508 Standards impose significant constraints on this option.


The best way to meet the Revised 508 Standards is to use the ACOP test guidelines, which have been designed to produce repeatable results and harmonize test practices across Federal agencies. The rule sets establish a minimum set of requirements, and you are encouraged to improve upon them.

Content Types

All public facing electronic content, including applications and interactive content, must meet the Revised 508 Standards.  All internal-facing electronic content that falls within at least one of the nine categories of “Agency Official Communications” found in Section E205 must be accessible.


Assess how accessibility is addressed in the rule sets your agency uses, to determine the type and extent of training you will need. If your development and authoring best practices and test rules do not currently address accessibility, it will take you longer to learn to test content for accessibility than it would if you were merely updating current practices aimed at meeting the Original 508 Standards. The harmonized test processes published by the ACOP already incorporate most of the Revised 508 Standards.

Automated Scanning Tools

Automated testing for WCAG 2.0 conformance is not new. There are several types of tools, including workstation-based, server-based, and hybrid tools.  Workstation-based tools generally cost less, and can be helpful for small volumes of electronic content, or for small development group use.  Server-based tools are generally higher cost but can help larger organizations assess large amounts of electronic content, and can help dispersed development groups more effectively share conformance test results.  Hybrid automated tools require significant upfront planning and implementation work, but can be integrated into existing development or authoring workflows using application programming interfaces (APIs), with great results.

Automated evaluation tools reduce but rarely eliminate the need for manual accessibility testing, because human judgment is often required to determine conformance.  While automated tools are helpful when used properly, improper use can result in false assurances of conformance or, at a minimum, confusion among authors and developers.

If you plan to use automated evaluation tools, validate them against the Revised 508 Standards to know if they evaluate content correctly and produce consistent results.  Address issues of incorrect, inconsistent, or incomplete results upfront during implementation.

Ask for validation data from prospective automated tool sources.  Decide how automated test rules can be modified if you find inaccuracies, and determine how you will maintain your test rules.

Automated web evaluation tools should test HTML as it appears on the rendered page in the browser document object model (DOM).  Tools should evaluate against what end-users will experience.  Will the test results be used with associated manual test results, as periodic bulk rough measures of conformance, to track progress towards a goal, or for some other purpose?  If you are using automated tools to locate trouble spots, you need to have a consistent way to identify and rank the severity of failures, and a reasonable way to aggregate such information for reporting.

Automated vs. Manual Testing

When purely yes/no answers are required, even if they are a complicated set of true/false logical conditions, automated tools can do well.  However, automated tools cannot compare various options for remediation against one another, or determine if the accessibility error must be remediated.

For example, automated tools can easily identify if an image element has an alt attribute, and possibly if the text content in the alt attribute is insufficient (e.g., a filename). However, automated tools cannot determine if an image is decorative, or if the text in the alt attribute appropriately describes the important information in the image. Such an evaluation requires understanding of what content, if any, the image conveys, and how best to describe the content in context. This is an example of where an automated testing tool is no substitute for human judgment.

Learn more about testing algorithms:

You may need to revalidate your testing results, since the WCAG 2.0 Level AA algorithms used by automated testing tools differ somewhat from those used for the Original 508 Standards (which were largely based on WCAG 1.0).  If you use automated evaluation tools for Microsoft SharePoint sites, consider how Microsoft SharePoint works, and how the automated rules work in conjunction, to avoid false negative or positive results.

Authoring Tool Requirements

The Revised 508 Standards include new requirements for authoring tools.  From the definitions section (E103.4) of the Revised 508 Standards:

Authoring Tool: any software, or collection of software components, that can be used by authors, alone or collaboratively, to create or modify content for use by others, including other authors.

Examples include:

  • Word processors
  • Presentation creation tools
  • Video editing tools
  • Software used to develop software
  • Web content management systems (CMS)
  • Collaboration software
  • Wikis, and
  • Conferencing/meeting software with an authoring tool in its feature set.

The Revised 508 Standards include an exception when working in a raw text format, so an application such as Notepad (which can be used as an authoring tool) complies with the Revised 508 Standards, because it only functions as an editor of plain text files.

If accessibility is not considered from the start of the creative process, special (and often-unsuccessful) workarounds must be employed to make the output accessible (i.e., meet the standards).  Such workarounds are usually found by trial and error, rarely documented, and usually not shared within the authoring or developer community.  In the worst case, accessibility simply may not be addressed because authors and developers are unaware of their responsibilities, or the resources available to meet those responsibilities.

Output Requirements

Because electronic content is specifically called out in the Revised 508 Standards, authoring tools must allow the author to produce output that conforms to WCAG Level A and Level AA Success Criteria and Conformance Requirements.

See Section 504 of the Revised 508 Standards for specifics. Topics include:

  • 504.2 Content Creation or Editing - Ensures that authoring tools allow you to create or edit accessible content
  • 504.2.1 Preservation of Information Provided for Accessibility in Format Conversion - When converting content from one format to another, or saving content in multiple formats, ensures that authoring tools preserve as much accessibility information as possible
  • 504.2.2 PDF Export - Ensures that you don’t lose accessibility information when converting from one format to another
  • 504.3 Prompts - Ensures that authoring tools prompt you to create accessible content; for example, when adding images, the tool should prompt you to add alternative text
  • 504.4 Templates - Ensures that those authoring tools that come with templates include some that are accessible

If your software lets you create or edit content, or save content in PDF format, then the software is probably an authoring tool. Determine whether the software meets the above requirements by either asking the vendor, testing the tool, or both.  Also request the vendor provide samples (also known as reference outputs) of at least one example of every type of interface element.  The sample might be as simple as a PDF report, or as complicated as a complete application or website.  Use the samples to test the interface elements, so you’ll know if the software is conformant (or not).

Clear authoring guidelines are usually a good indication that those tools can produce accessible outputs.  See these Testing Resources for examples.

Accessibility Training for Developers

General Training


The International Association of Accessibility Professionals (IAAP) offers two accessibility certifications:

Prepare for the IAAP certifications:

If you complete both certifications above, you’ll also receive a Certified Professional in Web Accessibility (CPWA) designation.

Education Initiatives

  • Teach Access - Aims to expand the quality and quantity of undergraduate programs that teach accessibility fundamentals in fields such as design, computer science, and human computer interaction

Web Accessibility Training

These resources (including some no-cost offerings) can help you understand how accessibility is achieved in certain specialized environments. You must understand your development environment to determine what, specifically, you’ll need to know.

Original 508 Standards

A number of organizations offer training based on the Original 508 Standards. Though the Standards have been revised, many are still valuable, including:

Web Accessibility

More modern resources include:

Developing Accessible Web Content

Review the W3C’s Sufficient Techniques for examples of how to meet Success Criteria using specific technologies (relevant to HTML, CSS, server-side scripting, Flash, ARIA, etc.).

Content Authoring Guidelines

Open Source Code and Frameworks

Open source code has additional requirements to make the content accessible.

JavaScript Frameworks

Contributors to these JavaScript frameworks actively consider accessibility in development:

  • JQuery - the “grandfather” of JavaScript frameworks; this article specifically addresses how to create accessible forms
  • React.js - web application development framework from Facebook
  • Angular.js - web development framework from Google
  • Bootstrap.js - JavaScript development framework from Twitter
  • ext.js - JavaScript development framework
  • ally.js - JavaScript library to make accessibility simpler for modern web applications



Development Environments

Testing Tools

Captioning Tools and Resources

Other References

Legislation and Standards

Section 508 Refresh

W3C WCAG 2.0 References

The W3C is an internationally recognized web standards body that identifies its approved technical specification standards as “W3C Recommendations” (such as HTML, CSS, etc.). The consortium has several Accessibility specifications that have achieved W3C Recommendation status, including WCAG, ATAG, and WAI-ARIA. Other accessibility-related W3C recommendations – such as the User Agent Accessibility Guidelines are also relevant.

These best practices were developed by the U.S. Federal Government Authoring and Developer Transition Working Group, with contributions from the Federal CIO Council’s Accessibility Community of Practice (ACoP), the U.S. Access Board, and the General Services Administration.

Page Reviewed/Updated: December 2017