fbpx

Web Content Accessibility Guidelines (WCAG) – Enhancing Digital Accessibility and Usability for the Web

Each year, hundreds of thousands of people who are disabled are denied access to information and services via the web. From commercial websites to digital learning tools, to online government services, the internet is littered with inaccessible content. Building and maintaining accessible web content and applications can be challenging. Thankfully, there are web-focused accessibility experts, guidelines, and tools out there to help you. Integrating all three of these components into your web content and technology development, or remediation, can ensure you meet and sustain compliance.

Help increase access to web content for your users and their assistive technologies by implementing WCAG standards into your web development. Accessibility first web design ensures that you and your content will remain at the forefront of both legal compliance and equitable access. Follow this overview of the WCAG guidelines, validation tools, and web accessibility support to learn more.

Introduction to WCAG

WCAG stands for the Web Content Accessibility Guidelines. WCAG is an internationally recognized standard for making the web more accessible to people with disabilities, assistive technologies, or more generally those who would benefit from alternative forms of access.

Advocating accessibility first in designing and developing the web, the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) has published three major releases of the WCAG guidelines:

  • WCAG 1.0 (May 5, 1999)
  • WCAG 2.0 (December 11, 2008)
  • WCAG 2.1 (June 5, 2018)

WCAG 1.0

In 1999, the WAI released its first set of 14 web-content accessibility guidelines (WCAG 1.0). This first edition helped to situate developers to the challenges facing many accessibility users:

  • They may not be able to see, hear, move, or may not be able to process some types of information easily or at all;
  • They may have difficulty reading or comprehending text;
  • They may not have or be able to use a keyboard or mouse;
  • They may have a text-only screen, a small screen, or a slow Internet connection;
  • They may not speak or understand fluently the language in which the document is written;
  • They may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g., driving to work, working in a loud environment, etc.);
  • They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system;

(WCAG 1.0, 1. Introduction. Accessed: March 27, 2019.)

Each guideline offered assessment checkpoints, which described the issue area and linked to “techniques” for accessible web content implementation. WCAG 1.0 also introduced an assessment framework within which developers could both test and demonstrate conformance based on the satisfaction of three priority levels applied to a guideline checkpoint.

Conformance was, and continues to be, measured against three levels:

  • A: (Level “A”) all Priority 1 checkpoints are satisfied;
  • AA: (Level “Double-A”) all Priority 1 and 2 checkpoints are satisfied;
  • AAA: (Level “Triple-A”) all Priority 1, 2, and 3 checkpoints are satisfied;

(WCAG 1.0, 5. Conformance. Accessed: March 27, 2019.)

1. Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

2. Operable

User interface components and navigation must be operable.

3. Understandable

Information and the operation of user interface must be understandable.

4. Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

WCAG 2.1

In 2018, WCAG 2.1 introduced new success criteria “to improve accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices.” Newly added criteria are as follows:

(WCAG 2.1, 0.5.1 New Features in WCAG 2.1. Accessed March 27, 2019)

WCAG Compliance (Levels A, AA, AA)

Compliance in this context means that all web content and authoring tools conform to the success criteria established by the guidelines and at the appropriate conformance level (A, AA, or AAA).

WCAG 2.1 conformance is defined in section 5 of the guidelines (WCAG 2.1, 5. Conformance) and discussed at length in the article Understanding Conformance.

There are 5 stated “Requirements” for conformance:

1. Conformance level

  • Level A: minimum level required
  • Level AA: extended*
  • Level AAA: all criteria of the guidelines have been satisfied**

*Level AA is most commonly the recommended level of conformance for accessible web content and technologies.

**Level AAA is not recommended by WCAG 2.1 working group because there are content types that cannot be made accessible at this point.

2. Full pages

Conformance is tested at the level of a “Full page,” which includes all content inside the author’s control of the entire web page:

Web page: a non-embedded resource obtained from a single URL using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent (WCAG 2.1, 6. Glossary: “Web Page.” Accessed March 27, 2019).

In cases where the content or application of a web page cannot be remediated to meet minimum conformance, an alternative version can be introduced. The minimum requirement is that these technologies do not “interfere with the rest of the page and all information and function is available elsewhere on or from the page.”

If an author cannot meet full conformance for a particular component of a web page, or produce an alternative version, a Statement of Partial Conformance can be employed.

3. Complete processes

When multiple web pages constitute a process or a series, all pages must meet minimum conformance.

4. Only accessibility-supported ways of using technologies

Technologies must be designed so that all content and functionality is made available to an accessibility user and assistive technologies. This also covers continued development of assistive technologies to support emerging web content frameworks or technologies.

5. Non-interference

Technologies do not interfere with an accessibility user’s interaction with content; that they can pause, stop, hide (i.e., control) such technologies without losing access to content of web page.

WCAG Validators and Automated Testing

WCAG validation tools programmatically test your web content or technologies for accessibility conformance against WCAG guidelines. There are also tools that automate testing against other conformance rules, such as Section 508 or industry specific standards.

Browse WAI’s Web Accessibility Evaluation Tools List.

From browser add-ons to CMS plugins, to mobile applications, to development software and content authoring tools, accessibility validators support a broad range of development contexts. Because many accessibility issues can be addressed at the code level, automated validation tools can help developers (and others) rapidly generate reports on possible accessibility errors and warnings. Typical validators provide a summary of potential issues with further information explaining the identified issues against compliance guidelines specified by the application and in some cases by the user. Some even go so far as to suggest steps and examples for remediation.

Validation tools are a necessary part of any developer’s accessibility toolkit. They should be used regularly to help aid in accessibility-first web content and technology development. However, validators should never be used as a replacement to an accessibility specialist. All forms of automated testing require a trained human agent to select tools, run tests, and assess the results. Not all tools are equal, nor do they satisfy all accessibility concerns or contexts. They are not always accurate in their reporting, and no tool can catch all accessibility issues. One must know in what contexts and ways a tool should or shouldn’t be used. The effectiveness of a tool in identifying accessibility issues and guiding accessibility-first development depends greatly on,

  • the content, technology, or environment being tested;
  • the development and accessibility experience of the tester;
  • the context of usability (from the user community to the assistive technologies employed);
  • and of course, the stages of assessment and development in which the tool is being implemented.

FAQ

Is there a recommended WCAG compliance level?

Yes. Level AA is generally recommended.

Level A only demonstrates a minimum level of compliance of both WCAG, as well as standard coding practices set forth by our languages, applications, environments, and technologies. Level AAA demonstrates the highest level of conformance; however, even WCAG notes that while this can be satisfied in particular contexts, Level AAA conformance cannot be achieved for all web content or technologies that may exist in an application or environment.

Does WCAG compliance ensure usability?

No. “Compliance” does not guarantee usability. Assessment of usability is a complex process of developing and testing your web content and technologies against the actual experiences of accessibility users. WCAG compliance is based on a general set of technical guidelines and checklists intended to broadly educate the web development community about known accessibility issues in the context of current coding standards and technologies. As the guidelines are evolving, so too are the conditions for access based on changing encoding practices, emerging assistive technologies, and increased advocacy for the accessibility community.

Do WCAG validators work?

As with any program, if it runs, it technical works, but statistically, even the best validators will only provide about 40% accuracy. Validators can provide a good starting point but even the best programs cannot catch all accessibility issues. All automated testing requires an experienced accessibility specialist to run and understand the results so that a more detailed plan of testing can be developed. Learn more by reading the section above: “WCAG Validators and Automated Testing.”

If I pass a WCAG validator, do I need an additional review?

Yes. Oftentimes the concept of “Pass vs. Fail” employed by these tools can be misleading. Because most validators are either designed for “general” application or context specific use, the meaningfulness of a pass or a fail is likewise either generalized or limited. If you are unfamiliar with web content accessibility or development, SeeWriteHear can help. We’ll assist you in selecting a tool appropriate for your development context, and educate you about the kinds of required assessment not supported by automated validation.