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 email@example.com.
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.
- Instructions - Revised 508 Standards Applicability Checklist - learn how to apply the Standards to your work
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.
- Electronic documents must meet the W3C WCAG 2.0, Level A and AA guidelines (with four exceptions); see 36 CFR 1194 E205 electronic Content, and E205.4 Accessibility Standards
- For web content, see E205, E205.2 and E205.3
- For hardware, see E206 and Chapter 5, 501
- For software, see E207, E207.2 and E207.3
- For authoring tools, see Chapter 5, 504
- For functional performance criteria, see E204 and Chapter 3, 301 and 302
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.2, E205 and E207 of the Revised 508 Standards impose significant constraints on this option.
- Understanding WCAG 2.0 Conformance - Guidance from the W3C
- Revised 508 Standards Toolkit - Overview and implementation guidance
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.
- Accessibility Testing for Electronic Content - ACOP test guidelines for web and apps, Microsoft Word, Excel and PowerPoint, and PDF documents
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:
- What Tenon Tests - automated scanning tool
- Functional Accessibility Evaluator 2.0 - automated scanning tool
- Deque’s aXe-core - integrated solution
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.
- 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.
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
The International Association of Accessibility Professionals (IAAP) offers two accessibility certifications:
- Certified Professional in Accessibility Core Competency (CPACC) - about CPACC certification
- Web Accessibility Specialist (WAS) - about WAS certification
Prepare for the IAAP certifications:
- WAS Credential Content Outline
- CPACC Body of Knowledge - Prepare for the CPACC Exam
- WAS Body of Knowledge (MS Word)
- IAAP Approved Certification Preparation Providers
If you complete both certifications above, you’ll also receive a Certified Professional in Web Accessibility (CPWA) designation.
- 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
- Teach Access Tutorial - learn about mobile app and website accessibility
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:
- Department of Homeland Security (DHS) Trusted Tester Certification
- Department of Veterans Affairs (VA) - Creating Accessible Flash
- Accessibility Community of Practice (ACOP) Best Practices Library
More modern resources include:
- Rob Dodson from Google has a great introductory talk
- Google’s Introduction to Web Accessibility introduces tools and techniques for web developers to easily ensure that websites are more accessible
- Web Accessibility | Udacity offers hands-on experience to make web applications accessible
- The Code4Lib Journal – A Practical Guide on Developing Accessible Websites
- Making Microsoft Office Documents Accessible
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.).
- How to Meet WCAG 2.0 - quick reference guide
- Getting started with web accessibility
- Designing for inclusion
- Selecting web accessibility evaluation tools
- Applying WCAG 2.0 to non-web content
- WCAG tutorials
Content Authoring Guidelines
- IT Accessibility Checklist - University of Washington
- The Code4Lib Journal – A Practical Guide on Developing Accessible Websites
- Web Accessibility In Mind (WebAIM)
Open Source Code and Frameworks
Open source code has additional requirements to make the content accessible.
- Making Open-Source Accessible for All - Medium article
- Why Open Source Needs Accessibility Standards - opensourse.com article on the responsibility for developers to make open-source code accessible
- Open Source Accessibility initiative (OSAi) - Advocates for open and compliant digital solutions, and promotes accessibility in open-source projects
- React.js - web application development framework from Facebook
- Angular.js - web development framework from Google
- BBC Mobile Accessibility Guidelines
- Apple Accessibility Programing Guide for IOS
- Google Accessibility for Android Developers
- Apple Accessibility programming Guide for OSX
- Introduction to Microsoft UI Automation
- Microsoft UI Automation Overview
- Oracle Product Accessibility Guidance
Captioning Tools and Resources
- Section 508 Resources - Compiled by Veterans Administration Section 508 Office
- Adobe Captivate 9 Accessibility Authoring Guidance
Legislation and Standards
- Section 508 of the Rehabilitation Act (29 U.S.C. § 794d), as amended by the Workforce Investment Act of 1998 (P.L. 105-220)
- Original Section 508 Standards
- Revised 508 Standards (revised January 2017, effective January 2018)
- Revised 508 Standards Functional Performance Criteria
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.
- An Introduction to Understanding WCAG 2.0, (Mar. 17, 2016)
- Understanding WCAG 2.0
- WCAG Quick Reference
- WAI-ARIA Authoring Best Practices
- W3C Authoring Tool Accessibility Guidelines
- W3C User Agent Accessibility Guidelines
- SVG Accessibility Mappings
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