The fifth of June 2018 saw a lot of buzz in the world of digital accessibility, social media and in blogs. What was this all about? Well, many may know; if no, wake up to hear, read and see Web Content Accessibility Guidelines 2.1 becoming the published recommendation. Yes, on June 5, 2018, W3C published WCAG 2.1 as its recommendation. While accessibility professionals and disability advocates rejoice on this, the businesses and even professionals too may have so many questions. It’s just an attempt to clear the mystery.
How does WCAG 2.1 differ from WCAG 2.0?
WCAG 2.1 does not differ from WCAG 2.0 in so many counts. In fact, WCAG 2.1 has taken all the success criteria of WCAG 2.0 in verbatim (word by word) and holds them intact. The conformance levels (A) (AA) and (AAA) also remain the same. In other words, a website has to meet WCAG 2.0 in order to meet WCAG 2.1. But the new guidelines don’t stop there. WCAG 2.1 introduces 17 new success criteria in order to address the user needs of low vision, cognitive and mobile users.
The new success criteria are carefully drafted after an extensive research on user needs. So they all come up with personas for better understanding and implementation.
What’s behind this?
WCAG 2.0 will be completing its 10th anniversary this December as it became a recommendation on December 11, 2008. In these 10 years, many have felt that a lot has changed in the technology landscape and in the needs of the users too. For example, WCAG 2.0 did not address as many needs of users with low vision and users with cognitive disabilities as it addressed other user groups like screen reader users. Besides, the web has entered into our palm with the hand-held mobile devices and that has imposed a lot of challenges in the accessibility canvas. To address all these gaps, the Web Accessibility Initiative (WAI) of W3C with its task forces have brought out the minor top-up called WCAG 2.1.
WCAG being as explicit as ever has created this update in over a year and a half, publishing its first draft in Jan 2017, publishing its final draft in Jan 2018, making it a proposed recommendation in April 2018 and after an extensive review, finally declaring as the published recommendation on June 5, 2018. Even though it is a short span, WCAG 2.1 is strong enough in its technical explicitness and addressing user needs which are both futuristic and viable.
The following tables throw a glimpse of the new Success Criteria for our understanding and a quick reference:
|Success Criterion||Description||For whom it’s meant||Conformance Level|
|1.3.4 – Orientation||Content does not restrict its view and operation to a single display orientation, such as portrait or landscape unless a specific display orientation is essential.||Wheelchair users who mount their mobile devices and view the content in one specific orientation||AA|
|1.3.5 – Identify Input Purpose||The purpose of each input field collecting information about the user can be programmatically determined when:
||People with reading disabilities who cannot remember so much of numbers and data and type them out||AA|
|1.3.6 – Identify Purpose||In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.||People with cognitive disabilities such as language disabilities who use software to identify common navigation links with symbols||AAA|
|Success Criterion||Description||For whom it’s meant||Conformance level|
|1.4.10 – Reflow||Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
Except for parts of the content which require two-dimensional layout for usage or meaning.
|People with low vision who have to resize the text to 400% and still be able to read without having to scroll right/left to read each line or up and down.||AA|
|1.4.11 – Non-text Contrast||The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):
||People who have contrast sensitivity and need to see icons, borders of the user interface and graphs even in the sunlight||AA|
|1.4.12 – Text Spacing||In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can confirm using only the properties that exist for that combination of language and script.
|People with reading disabilities and need enough spacing between characters, words, paragraphs, and lines||AA|
|1.4.13 – Content on hover or focus||Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:
Exception: The visual presentation of the additional content is controlled by the user agent and is
|People with low vision who use magnification and need to move to the additional content and get away from it||AA|
2.1 Keyboard Accessible
|Success Criterion||Description||For whom its meant||Conformance Level|
|2.1.4 – Character Key Shortcuts||If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:
||People who use speech recognition software and dictate their tasks to the system d not activate something by saying the single letter keyboard shortcuts.||A|
|2.2.6 – Timeouts||Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions.||People with cognitive disabilities, blind and low vision who take time to read.||AAA|
|2.3.3 – Animation Triggered by Interaction||Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.||People who have cognitive, neural disorders and experience dizziness and nausea due to motion animation.||AAA|
|2.5.1 – Pointer gestures||All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.||People with limited finger movements, who use large cursors and who have low vision||A|
|2.5.2 – Pointer Cancellation||For functionality that can be operated using a single pointer, at least one of the following is true:
||People with motor disabilities who may trigger actions accidentally by touching an element.||A|
|2.5.3 – Label in Name||For user interface components with labels that include text or images of text, the name contains the text that is presented visually.||People who use speech recognition software and would activate elements based on the text label visible on the screen.||A|
|2.5.4 – Motion Actuation||Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:
||People who have motor disabilities and cannot interact with functionalities through motion.||A|
|2.5.5 – Target Size||The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:
||People with motor disabilities like hand tremor need a bigger target size or clickable area.||AAA|
|2.5.6 – Concurrent Input Mechanisms||Web content does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings.||People with repetitive stress injury who need to use different input devices like keyboard or styles as and when they want.||AAA|
|Success Criterion||Description||For Whom It’s Meant||Conformance Level|
|4.1.3 – Status Messages||In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.||People who are blind and low vision and use screen reader need to know the status updates that are visual and textual without moving the focus.||AA|
WCAG 2.1 is futuristic than ever before that some of the requirements need the development of technologies and more specifically within the markup languages. So how it is going to turn the a11y table around is something we all have to wait and watch.
Who Knows! The scope of assistive technology may be extended further to assist people with disabilities in a robust way. With all these requirements and evolving assistive technology combined with the power of AI, the accessibility may spread its wings into hitherto un-flown skies. Let’s hope for the best!