For people that work in the web accessibity area, today’s news that the World Wide Web Consortium (W3C) has now made publically available the first draft of the Web Content Accessibility Guidelines (WCAG) 2.1 public draft is very exciting. In order for people with disabilities to use computers and Internet-related technologies, two things need to happen: the first is that people with disabilities get the tools they need on the device they want to use to assist them to access content, the second is that content needs to be designed in a way that works with those tool’s. This discussion looks at the second part of that requirement: what developers need to do to make sure that content is designed in a way that supports the needs of people with disabilities and the assistive technologies they use.
For the benefit of people new to accessibility, the current definitive world standard for this is called the Web Content Accessibility Guidelines (WCAG) 2.0, published in December 2008. However the world was very different nine years ago in terms of technology support for people with disabilities. For example, the first iPhone that people who are blind or vision impaired could use didn’t come out until 2009. As such the standard needed updating and the first part of that update is WCAG 2.1.
As noted in the W3C Web Accessibility Initiative (WAI) landing page, “This first draft includes 28 new Success Criteria, three of which have been formally accepted by the Working Group and the remainder included as proposals to provide an opportunity for early feedback.”
So with today marking our first chance to look at WCAG 2.1, its worth considering two questions; what’s the current thinking of the Accessibility Guidelines Working Group (AG WG)? and what are the new success criteria being proposed?
WCAG 2.1 – improved inclusivity for people and devices
The first paragraph of the WCAG 2.1 abstract answers the first question, and it’s very much in line with what has been called for in recent years – a greater inclusion of cognitive-related disability support and specific guidance on a range of devices including the specific naming of mobiles and tablets. To quote the abstract:
“Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity, and combinations of these. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make your Web content more usable to users in general.”
The last point is a particularly good addition. It’s often argued that accessibity is not just helpful to people with disabilities, but in fact helpful to everyone, and it’s great to see that point made in the draft.
Before moving on to discussion of the specific Success Criteria (SC), there’s a few important points to note about the approach of the AG WG:
- They are not currently changing anything in WCAG 2.0. While this means there’s overlap and redundancy, they are first focusing on the things that WCAG 2.0 does not cover before adjusting the terminology and teaching of the current standard.
- Only three of the 28 proposed SC have been adopted by the AG WG. As such there’s still a lot of room to move and this provides a fantastic opportunity for public feedback.
- Compliance with WCAG 2.1 will also result in compliance with WCAG 2.0. This is referenced in a few places and provides confidence that the final version of WCAG 2.1 will be both effective and compatible with current policy frameworks.
In my opinion the development path is a sensible one. It makes sense to plug the holes of WCAG 2.0 first, and then renovate the existing standard later. As with all W3C working groups there’s a lot of moving parts when work is being developed so things can change quickly, and often in exciting ways.
Approved new success criteria proposals
There are currently three SC that have been approved by the AG WG. They are:
- 1.4.11 Resize content (Level A): Content can be resized to 400% without loss of content or functionality, and without requiring two-dimensional scrolling except for parts of the content where fixed spatial layout is necessary to use or meaning
- 1.4.12 Graphics Contrast (Level AA): The visual presentation of graphical objects that are essential for understanding the content or functionality have a contrast ratio of at least 4.5:1 against the adjacent color(s), except for the following:
- 2.2.8 Interruptions (minimum) (Level AA): There is an easily available mechanism to postpone and suppress interruptions and changes in content unless they are initiated by the user or involve an emergency.
The first of these takes into account a common issue on mobiles whereby making content bigger has a habit of breaking the website as even now there’s an assumption that people are viewing websites on desktops with large screens. With responsive design not being around much in 2008 it’s great to see an SC highlighting the need to ensure that if text is increased it won’t break things. It also addresses the presence of unwieldy scroll bars which become particularly challenging if you are using screen magnification tools on a mobile device.
Graphics contrast is also a great addition, clarifying a long-standing issue with WCAG 2.0 in that the 4.5:1 Level AA contrast is quite clear, but how it specifically relates to graphics is not. This is now addressed, along with important exceptions such as logos for images that have to have specific colours otherwise content is lost. My only concern relates to the ‘essential’ point which could be a loophole for people to put anything they like on a website arguing the colours have to be that way, but perhaps this will be further clarified during the review process. Each of the bullet points for this criteria have additional information which can be viewed at the linked resource.
The final point is one for which I cheer. With ARIA support becoming more common and a greater ability for developers to take charge of assistive technologies, there’s a lot of ways the process of assistive technology such as a screen reader can be interrupted. This SC is a logical progression of existing SC that relate to auto-updates and I hope this remains largely unchanged.
For the remaining 25 SC that are proposed but not yet approved by the AG WG, I’ve just noted a few thoughts. You can read more about the details of the specific SC information by following the respective links.
Proposed success criteria
Guideline 1.3 additions
There’s one new proposed SC for guideline 1.3:
I agree with ethologic of separating this out from the broader sensory characteristics, but in my opinion more information is needed to explain the scenarios and why WCAG 2.0 doesn’t currently address this already.
Guideline 1.4 additions
Addressing issues relating to seeing and hearing content featured highly in the update
Starting with linearization, I’m a big fan of this one. It essentially proposes that content can be viewed as a single column. In the era of responsive design and mobile use as mentioned earlier, this would be absolutely fantastic and I hope it gets up.
This second SC states that ‘If content can printed’ (I think the word ‘be’ is missing) then you can have some flexibility in how the content is presented. I can appreciate the reason why this is here but personally I don’t think it’s such a critical issue that it needs to be in WCAG. I’m conscious that the more SC that are added the more work it will be for developers, and personally I don’t see printing as a priority.
The next SC looks at specific contrast requirements for user interface elements. I can certainly see the logic and importance, but I’d thought this has already large covered in WCAG 2.0. Would be good to see some additional information on the context.
The Adapting Text SC would be a fantastic addition. As a high contrast color user its often the case that websites don’t account for user-defined colors and you end up in situations where text gets garbled or you can end up with for example, black text on a black background. The specifics of this need some work but I’m a big fan of the principle.
For the last SC on the list I’m not entirely sure about this one. The idea is that there’s more control around On Hover and On Focus. It seems like a logical improvement to On Focus in WCAG 2.0 rather than a standalone SC.
Guideline 2.1 additions
There’s only one new proposed change to keyboard accessibility SC, but it’s a big one.
This SC adds a requirement that speech input is not obstructed. This is a great additional and reflects the changing nature of how we are interacting with our devices through features such as digital assistants and there’s clear Internet of Things implications here. In the long run I suspect the whole guideline’s terminology will need to be changed from ‘keyboard accessible’ to something more broad, but this SC is a great addition and reflects the changing way people with disabilities are interacting with their devices.
Guideline 2.2 additions
There’s two proposed SC relating to timing:
When I saw the timeout criteria I wanted to leap from my chair and punch he air in celebration. Few things are more frustrating than having websites timeout when you’re trying to complete an online task. While developers have often tried to address the issue, there’s been little guidance from WCAG as to what is best practice – until now. I’m not sure on the point about a one week data retention as I can’t see the basis for that specific time period, but I’m very excited about this SC being n there and really looking forward to its refinement as the WCAG 2.1 process continues. The second SC seems relatively minor by comparison and perhaps this will be folded into an existing WCAG 2.0 SC.
Guideline 2.4 additions
There’s one proposed SC about helping users navigate and find content:
The statement for this SC is ‘Single-character shortcuts are not the only way activate a control, unless a mechanism is available to turn them off or remap them to shortcuts with two or more characters.’ If I understand the concept correctly it seems like a good idea but the language here seems a bit clunky and it’d be good to tidy up the wording.
New proposed guides 2.5 and 2.6 Pointer Accessible and Additional Sensor Inputs
In the current WCAG 2.1 there are two new guidelines proposed to provide specific guidance in WCAG for mobile content. It makes it easier for users to operate pointer functionality and touchscreen interfaces. The SC for 2.5 includes:
These four SC essentially explain how touch interfaces should work, what size area should be allocated for touch to be accessible, how that varies depending on the pointer devices and the accessibility of specific gestures in the content itself, separate from the browser or device interface. While all these things are important and really highlight why WCAG 2.1 is needed, the standout point for me is touch with assistive technology.
Its remarkable how often aps work great before I turn on the screen reader on my phone, and how completely inaccessible it becomes once the screen reader is enabled. While the other SC are quite specific, it’s this broad requirement of AT compatibility that I suspect will be one of the greatest arguments put forward for moving to WCAG 2.1 and it’s my hope that this is adopted by the AG WG as soon as possible.
In regards to Guideline 2.6, there’s not much detail yet about how the guideline is defined, but the two related SC are as follows:
I like the second SC as it’s amazing how often an app on a smartphone can break if you try to use it in a different orientation to what is expected, especially in the location and use of buttons, some of which disappear completely when the orientation is changed.
Guideline 3.1 additions
There are three proposed updates to the use of language:
There’s two things I really like about these proposed SC. Firstly, it’s a good compromise between making the essential things clear such as how to structure instructions and where common language is needed, but doesn’t restrict the actual language of a website. Secondly, it brings cognitive accessibility to Level A and AA which is long overdue. In my opinion the focus on improving language and structure in content with some exceptions has the right balance and I’m looking forward to seeing this progressed further.
Guideline 3.2 additions
There are three updates for helping content to work in predictable ways:
All three of these SC seem like pretty common-sense requirements to me, ensuring consistent and expected operation and likely issues that can cause confusion in a mobile environment such as accidental activation. Will be interesting to see the specifics as the SC are evolved.
Guideline 3.3 additions
To finish off the current round of updates, we see a number of proposed SC to help users avoid and correct mistakes.
I’m particularly excited to see the last two. The ability to go back and undo something or repair data in a straightforward manner is a great addition. I also like the idea that help information is provided although I’d prefer to see this as a Level A requirement.
Final thoughts on WCAG 2.1
Overall it’s been fantastic to see such a great first step by the AG WG in its development of the first WCAG 2.1 public draft. Many of the new SC are revolutionary and while I’m sure there’s still a lot of work to go, it’s off to a flying start. On a personal note as a person with a disability, it’s a wonderful thing to see pretty much everything on my wishlist appear here.
If you want to contribute to the WCAG 2.1 development, the AG WG are accepting public comment by e-mailing email@example.com. Comments close 31 March 2017.