Think back to the online landscape in 2008 it is amazing how much has evolved over the last decade. The biggest shift being from desktop/laptop to handheld computing, such as the iPhone you are most likely reading this on.
In 2008 your iPhone was a luxury, Twitter was brand new and YouTube wasn’t making millionaire influencers who play video games for a living. More importantly, we didn’t foresee the smartphone taking over pockets across the globe. Fast-forward to 2018 and the first update to the WCAG guidelines since 2008 are set to be released. Fundamental changes are coming to WCAG 2.1 that will see major changes in the mobile space, creating the next iteration of digital accessibility.
The new Web Content Accessibility Guidelines 2.1 (WCAG 2.1) will become a W3C recommendation, which will set the new standard on web content accessibility on an international level. For the Centre for Inclusive Design (a W3C member) and other Australian organisations, this is a major milestone that will change the way that Web content accessibility and inclusive design practices are assessed going forward.
What is WCAG?
The Web Content Accessibility Guidelines provide guidance on ensuring that your web content is accessible for people living with disabilities. The World Wide Web Consortium (W3C) released WCAG 1.0 back in 1999, and this version is now obsolete. This was replaced by WCAG 2.0 which is currently adopted and implemented by Australian government websites since the start of the National Transition Strategy in 2010. WCAG 2.1 is the next major web content accessibility guideline that is the long-awaited update for the nearly 10-year-old WCAG 2.0.
So, why should I care about WCAG?
WCAG 2.1 is a step towards creating an online space that is inclusive of all different people with all different abilities. Essentially WCAG ensures your content can reach and be engaged with by the widest possible audience. This decreases the need for additional communication, increases your reach and ensures your message is received. WCAG also has the added benefit of increasing your SEO!
Why was there a need for an update?
WCAG 2.0 is a guideline that was released back in December 2008, and it hasn’t changed since then. Back when 2.0 was released, Smartphones were still a very new technology and the foundations for what makes an accessible app or mobile website had not yet been established. Now in 2018, Smartphones are very common, and it’s best practice for new websites to incorporate a responsive design to support these devices.
The early smartphones released by Apple and shortly after Google were very inaccessible for people living with disabilities, and it wasn’t until the iPhone 3GS that the first inbuilt screen reader became available for vision-impaired users. Now in 2018, Smartphones often come loaded with accessibility features which benefit people with many different kinds of disabilities. Due to this, the adoption of people with disabilities using smartphones as their main way of accessing content is getting larger. WebAIM’s screen reader survey #7 reported that respondents using iOS and Android operating systems nearly tripled since 2015.
While WCAG 2.0 could be used to assess the accessibility of mobile websites and even apps, it had some clear gaps and some outdated terminology that didn’t quite make sense for the mobile platform. This forced accessibility specialists and auditors into a difficult position, as they had to translate WCAG 2.0 to work on mobile devices. Some examples of this are that WCAG 2.0 required keyboard access to all interactive components, but different interpretations were made for how this should apply to a mobile device. Responsive design also wasn’t a requirement in WCAG 2.0 (unlike in WCAG 2.1 with 1.4.10 Reflow (Level AA) being introduced), which meant that non-mobile friendly websites were technically conformant but didn’t meet the needs for people with disabilities using mobile devices.
In addition to this, after 10 years of critique, the WCAG 2.0 level ‘AA’ guideline was found to have some clear gaps for people with disabilities as well. For example, people who use voice-activated navigation often faced issues in WCAG 2.0 compliant websites, but this will be addressed in WCAG 2.1’s new success criterion, 2.5.3 Label in Name (Level A).
Does WCAG 2.1 replace WCAG 2.0?
Yes, WCAG 2.1 is the latest version of the Web Content Accessibility Guideline, but the W3C still recommends both WCAG 2.0 and WCAG 2.1. This is because WCAG 2.1 has been purposely designed to be completely backwards compatible with the 2.0 guideline, and doesn’t change or replace any of the requirements that were present before. This is good news for organisations, as any work already done on implementing WCAG 2.0 will not go to waste, and the new requirements can be implemented on top.
Does WCAG 2.1 still use the ‘A’, ‘AA’, ‘AAA’ conformance format?
Yes. This has remained largely the same to ensure backwards compatibility with the 2.0 guideline. WCAG 2.1 has 15 new success criteria that appear in all three conformance levels. For most websites, audits had been done using the WCAG 2.0 level ‘AA’ conformance level, with a much fewer number striving for the ‘AAA’ level of conformance. This is due to the Australian Government setting a requirement for all government websites to be WCAG 2.0 level ‘AA’ conformant.
Should I test with WCAG 2.0 or WCAG 2.1?
Currently, the only real reason you may want to audit your website with WCAG 2.0 over 2.1 is that Australian government websites only need to conform to WCAG 2.0 level ‘AA’. However, if you really want to ensure accessibility, particularly on your mobile devices, you should heavily consider auditing your website with the WCAG 2.1 guideline. As 2.1 is completely backwards compatible with 2.0 anyway, you’ll just be getting a little extra on your audit report which can often be really easy to implement, or help give you peace of mind on what’s already accessible.
For non-government organisations, there’s no reason at all why WCAG 2.1 shouldn’t be considered as you’ll be able to provide more access to more people by remediating issues that are only found in WCAG 2.1.
When building a new website or particularly an app, using WCAG 2.1 as your guideline is definitely a better option than WCAG 2.0 as it’ll be easier to work within the context of building your website’s mobile template or app.
What’s the Timeline for WCAG 2.1?
As of the writing of this article, WCAG 2.1 is expected to become a W3C recommendation in June 2018 and is expected to stay as the most updated version of the W3C’s Content Accessibility Guideline for the foreseeable future. WCAG 2.1 is currently in the Proposed Recommendation stage, meaning that it’s almost complete and despite this can be used to audit websites and mobile applications right now.
Even when the creation of WCAG 2.1 was in its early stages, the W3C has a long-term project planned known simply as the “Accessibility Guideline”, or “Silver” as it’s been code-named. WCAG 2.1 is just a quick update to the ageing WCAG 2.0 guideline, but Silver is expected to be a complete overhaul of the WCAG guidelines which covers far more than just Websites and Mobile phones, but potentially also driverless cars, Home voice assistants and other new technology that the future will bring.
The delivery date for Silver is currently uncertain, but it seems that WCAG 2.1 will be the guideline to focus on for at least the next three years.
What are the new requirements are in the guideline?
As mentioned earlier WCAG 2.1 has a much larger focus on mobile devices and some accessibility. Some of these new success criteria are:
1.3.4 ORIENTATION (LEVEL AA)
This success criterion makes it mandatory to have your websites and apps support both a portrait and landscape format. This is necessary as some people may be locked into either orientation, such as a phone being mounted onto a wheelchair.
1.4.10 REFLOW (LEVEL A)
Reflow makes mobile responsible design not just best practice for websites, but mandatory to meet WCAG 2.1. This requirement involves ensuring that your website is able to organise its content into a single column without the need to scroll horizontally to see content. This can be highly beneficial for some people, such as people living with low vision only needing to scroll up and down to find content, and people with cognitive disabilities may find a single-column layout easier to process.
1.4.11 NON-TEXT CONTRAST (LEVEL AA)
Non-text contrast is an extension of the 1.4.3 Contrast (minimum) success criterion found in WCAG 2.0. WCAG 2.0 only covered text colour contrast to ensure text always standout from its background to be sufficiently readable for elderly persons or people with low vision, but WCAG 2.1 extends this to icons and visual graphs which can often blend into the background as well and be difficult to read.
2.5.1 POINTER GESTURES (LEVEL A)
Pointer Gestures specifically relates to addressing the issue that some touch gestures on mobile devices can be difficult to perform for some users. This includes multi-touch gestures, such as pinching the screen to zoom in and out of a map, or path-based gestures such as scrolling to view all the options in the menu. While these functions are fine to have in your app or website, they should also be accommodated by single-touch buttons or controls that provides a much simpler way of performing an action. By having a visible button on screen, this can also benefit people who may not realise that they can swipe to perform an action.
2.5.2 POINTER CANCELLATION (LEVEL A)
This success criterion focuses on preventing accidental activation of controls. Not all of us have the best motor control, and can sometimes accidentally press a button that they didn’t intend to. Ensuring that controls don’t activate when you press down on a button, and only when you lift your finger up, can help to resolve this issue as well as having a method to abort or undo your action.
2.5.3 LABEL IN NAME (LEVEL A)
Label in Name refers to an issue specifically for people living with mobility impairments who use their voice to navigate their computer. An issue that can commonly occur when using voice-activated navigation is that the visible label on a button may not be the same as the name of the button in the code. When this occurs, the voice-activated software can get confused as the user wants to activate a button that the software cannot locate in the code, and therefore the user is stuck.
2.5.4 Motor Actuation (Level A)
This success criterion was created to address functionality that is controlled through device motion or user motion. A real example of this is the Hungry Jacks app, which requires you to shake your phone in order for you to claim free food. For many users, this kind of input is simply not possible and users need a way to do actions on their device without having to move their device. On the flip side, accidental activation can also occur when a user cannot control their movement, and so will need a way to disable motion-activated input.
Many more new success criteria exist in WCAG 2.1, which can be found in the WCAG 2.1 Guideline itself.
How we can help
If you are building a new website or want to improve the accessibility of your current website to reach more people, WCAG 2.1 will help to ensure your website can. The Centre for Inclusive Design has worked on several WCAG 2.1 audits already and can support your accessibility and inclusive design needs. Submit an enquiry about our services using our online form or contact one of our staff directly at practice@cfid.org.au or by phone at (02) 9212 6242.