WCAG 2.1 is a Candidate Recommendation
Author(s) and publish date
- By:
-
-
Andrew Kirkpatrick
-
- Published:
Web Content Accessibility Guidelines (WCAG) 2.1 is now a Candidate Recommendation (CR). The main purpose of Candidate Recommendation is to ensure that the standard can be implemented. The content is considered stable at this stage, but it it could change a little based on implementation experience.
Over the next few months, the Working Group will gather "implementations" of WCAG 2.1, that is, examples of websites that meet the WCAG 2.1 success criteria. Some success criteria are marked "at risk", which means that the Working Group is unsure if implementation testing or public review will validate those success criteria for the final guidelines. We especially seek implementation experience and input on these at-risk success criteria.
If you have web pages that you think meet WCAG 2.1 and would be useful to help validate implementability of the guidelines, especially for the newly proposed 2.1 success criteria, please submit them to [email protected].
Results of the Candidate Recommendation testing will be published in the WCAG 2.1 Implementation Report. Once testing is complete, WCAG 2.1 will be ready for the next stage.
We plan to publish the completed WCAG 2.1 by June 2018.
WCAG 2.1 Focus and Constraints
The focus for WCAG 2.1 has been to:
- Address more accessibility requirements for:
- people with cognitive and learning disabilities;
- people with low vision;
- mobile accessibility;
- Meet an ambitious timeline to publish the first Working Draft in February 2017 and complete it by June 2018.
In addition to the timeline, there are other constraints, including:
- WCAG requirements must be clear, implementable, technology neutral, objectively testable, and universally applicable.
- WCAG 2.1 needs to be "backwards compatible" with 2.0, that is, web pages that conform to WCAG 2.1 also conform to WCAG 2.0.
For more information on these requirements, see: Requirements for WCAG 2.1 and guidance on crafting success criteria.
As a dot-release, WCAG 2.1 could not address all issues that have been considered for future guidance, so the Accessibility Guidelines Working Group focused on addressing the most urgent and achievable issues on which they could reach consensus within in the timeline. Many good ideas had to be deferred because the Working Group could not develop solutions that met the WCAG requirements within the timeline. Stakeholders made many compromises to meet the overall goal of producing a useful standard on time. Of the over 70 success criteria initially proposed, 17 are in this Candidate Recommendation. While WCAG 2.1 does not cover all needs, particularly at Level A or AA, the Group is continuing work to address user needs in supporting material and future standards.
Supplemental Guidance and Future Standards
The Working Group hopes to produce supplemental material that provides more guidance on how to meet user needs. It would be "informative," rather than part of the WCAG 2.1 standard. It could cover issues more thoroughly because it would not be subject to the constraints to be objectively testable, technology neutral, etc.
The Working Group also continues work to include more accessibility requirements in future guidelines. A significant revision to accessibility guidelines is in development, which is code-named "Silver". This project will take several years. In the interim, the Working Group might decide to follow WCAG 2.1 with a 2.2 version to provide additional updates to address current accessibility requirements.
Thank You
Thank you to the Accessibility Guidelines Working Group, Cognitive and Learning Disabilities Accessibility Task Force, Low Vision Accessibility Task Force, Mobile Accessibility Task Force, and all who are contributing to getting WCAG 2.1 to Candidate Recommendation and on to finalization.
I am looking forward to reviewing the finalized WCAG 2.1. In the meantime I’ll search for content that I have that may meet these Guidlines
As a 508 Tester, this issue has become very critically important as it is the one that we have seen it continuously failing and making it harder for the user to utilize the tool as it was designed without having to repeatedly say “Tab. It definitely causes less effectiveness from the user due to how it is coded. User unable to gain focus by speaking labels when coded improperly.
Based on our current process, it must be added to the standard so that I can flag it so that it gets coded properly.
For WCAG 3.3.2, Labels and Instructions, add this question
“For edit fields, does the id and name fields match with the corresponding label for the field on the screen?”
This is an example of how it was coded:
Window Label on screen Coded
Content Content Object ID ID
Description Desc
Assessments Assignment ID ID
Assignment Name Desc
Objectives Object ID ID
Objective Name Objective
Description Desc
Holiday Holiday ID ID
Description Desc
Work Week Work Week Profile ID ID
Description WorkWeekDESC
Assignment Assignment Type ID ID
Description reqTypeDesc
Subject Area Subject Area ID ID
Description subjectDesc
Materials Material ID MaterialTypeId
Description MaterialTypeDescription
2. For WCAG 3.3.2: Labels and Instructions where it states “Are required fields clearly identified to the assistive technology?”
It would be better if it stated with more information to show it needs to be visual on screen as well as heard by screen readers.
“Are required fields clearly identified (visually for speech users and coded to be read for screen readers)?
3. For WCAG 3.3.2: Labels and Instructions, add an additional question
“Are any reserved words utilized for buttons, labels, checklists, or radio buttons?
Reserved words like “Home”, “Back”, “Type”, “Enter”, “File”, Edit”, “Insert”, “Search”, “Tools”, “Help”, “Close”, “Close all”, “Press”, Spell”, “Click”, Select all”, “Select”, “Review”, “Options”, “Word, “Excel”, “Start”, “Delete”, “Add”, “Start”, “Backspace”
4. For WCAG 3.3.2: Labels and Instructions, add an additional question
“Is there a “Cancel” button on each window within your application?”
This is important for testability of an application because when applications are designed with a button labeled “Close” it closes entire application.
This is important because when testing an application, for a dragon user, if they want to close window and return to previous window, if application contains a link for “Back” or “Close” rather than “Cancel” then user unable to speak the label since don’t get results as expect since “reserved words” and only use mouse grid to ensure they click on the correct button.
5. For WCAG 3.3.2: Labels and Instructions, add 2 additional questions that help with 508 usability of an application, as all users could benefit from this requirement
“If any abbreviations are utilized, is there a button or link to a page containing a glossary which helps users understand the meanings of the abbreviations used?”
--- this is important cause sometimes different abbreviations are used to mean the same thing on different screens at “pt” could mean patient or “part-time”
“If any terminology is utilized that is not easily understood by user, is there a button or link to an application dictionary for what the terms are utilized for?”
6. For WCAG 1.3.1: Info and Relationships, might include 3 additional questions to be more specific
a. Does user know where they are within a picklist (2 of 20) and which row and column within table?
b. Is window size and each column large enough for voice users to see all information within each field within table?
c. Can users navigate within any table left-right and up-down?
7. For WCAG 3.3.1 Error Handling, please include question should be added:
“When an error occurs, does the error message indicate to the user which specific field is in error and provide information on how to resolve?”
“For each error message, is it unique within the page?”