\n\nPublication as a W3C Recommendation finalizes the development process and indicates that the W3C considers the updated guidelines ready for implementation on web content.
\n
Last week WCAG 2.1 (Web Content Accessibility Guidelines) was recommended by the W3C, which means they have finished it and it’s ready for everyone to start implementing.
\nWCAG 2.0 was completed in 2008, back when touch devices were not as popular and tablets didn't exist yet. Since 2008 these devices have become the most prevalent way to access the web, but there were no success criteria that addressed accessibility for this input type. That is the main theme of WCAG 2.1: take into account touch devices. There are also a lot of new success criteria that address cognitive limitations too.
\nWithin WCAG there are three levels to conform to: A, AA, and AAA. Level A is the lowest bar of conformance and level AAA is the highest. These WCAG levels cascade, so if your app conforms to WCAG AA, it also conforms to WCAG A. Most companies shoot for AA since AAA has success criteria that are a little hard to reach and not all content can conform to AAA.
\nIn WCAG 2.1 there are:
\nLet's go over all 17 new success criteria to see what they are meant to solve and what it means for you. If you read the details for each of those success criteria some of them are straightforward and others aren’t. So I’m going to give my TL;DR version of the success criteria.
\nThere are five new success criteria for level A, which is the lowest level of conformance you can achieve (aka the easiest). The new success criteria are:
\nAssistive tech users have a lot of their own key combos for navigating and interaction. This success criterion is to ensure you don’t implement keyboard shortcuts that would prevent their functionality.
\nIf you have any custom keyboard shortcuts implemented, one of the following need to be true:
\nYou can read the reasoning for it and many more details here.
\nSince the last WCAG spec release there has been a lot of innovation on the web regarding touch devices. For example, with Google Maps you can use multi-touch gestures to pinch and zoom around the map.
\nThis success criterions says if there are multi-touch or slide gestures present, there must be a single input method also available. To keep with the maps example, there should be + and - buttons available to provide non-pointer gesture interactions for this success criterion to pass.
If the gesture is “essential” you may not need to worry about this one. They define “essential” as:
\n\n\nIf removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
\n
You can read the reasoning for it and many more details here.
\nFor interactions that can be done with a single pointer (clicks, single taps, long presses, etc.), you must provide a way to cancel it. One of the following must be true:
\ndown event (touchstart or mousedown)up event cancels the down event (this is like clicking a link, moving your cursor, and releasing)You can read the reasoning for it and many more details here.
\nSay you have an input with the visible label as “Name” and an aria-label as “Enter First Name”, this success criterion would fail. This is because speech input users navigate by saying the visible label. If the visible label doesn’t match the programmatic name (or accessible name) it will fail to navigate.
To drill it home with code, here’s two examples:
\n<!-- Bad -->\n<label for=\"name\">First Name</label>\n<input type=\"text\" id=\"name\" aria-label=\"Enter your first name\" />\n\n<!-- Good -->\n<label for=\"name\">First Name</label>\n<input type=\"text\" id=\"name\" />You can read the reasoning for it and many more details here.
\nIf you have an action that is triggered by motion, there must be a control on screen that performs the same action. For example, if you shake the device to undo text in an input, there should be a clear button available for single pointer devices to activate.
\nAnother example would be images you interact with by tilting your phone around. There should be buttons available that pan / tilt the picture too.
\nYou can read the reasoning for it and many more details here.
\nThere are seven new success criteria for level AA, which is the mid-level conformance you can achieve. The new success criteria are:
\nYour site or app should work in either orientation: landscape and portrait. Unless it’s deemed to be “essential” to the function of your app:
\n\n\nExamples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where binary display orientation is not applicable.
\n
You can read the reasoning for it and many more details here.
\nThe inputs on your page should fill in metadata to help the user better understand the intention of the form inputs. You can do this by adding autocomplete attributes to your inputs. This is a full list of input purposes.
You can read the reasoning for it and many more details here.
\nThis might be my favorite new success criterion! It essentially means your site or app should be responsive. If you can’t make your site or app responsive an alternative could be providing a fixed 320pxwidth version.
The explainer document linked below goes into great detail about why this decision was made and is a great resource for understanding how to pass this success criterion. I recommend reading through this one!
\nYou can read the reasoning for it and many more details here.
\nUI components and meaningful graphics must have a color contrast ratio of 3:1 to adjacent elements. This includes all states UI components can have (except the disabled state, which is confusing to me).
\nFor example, a button’s hover, active, and focus states must all pass the 3:1 color contrast ratio. This does not apply to inactive elements (like a disabled button).
\nYou can read the reasoning for it and many more details here.
\nContent on your site or app must be able to expand to the following requirements without any loss of content or functionality:
\nThat does not mean that your site or app has to implement the above requirements as a baseline. But it should be able to scale to those requirements without losing functionality or readability.
\nThis success criterion helps those who have low vision or dyslexia since they may override the default content styles to help reduce confusion while reading.
\nYou can read the reasoning for it and many more details here.
\nAny content that shows or hides from hover or focus needs to be:
\nThe key takeaway here is if you have content that appears due to an action, the user must have control over that content being shown or hidden. It can’t disappear without a explicit dismiss action from the user.
\nYou can read the reasoning for it and many more details here.
\nThe main focus of this success criterion is for screen reader users. When there is a change in content that does not change focus you should provide a status message to the screen reader. This is commonly known as the announcer pattern. I’ve written an ember addon for this and there is a react component that does this too.
\nAn example of this might be when an error on a form is displayed in a banner it should also announce that message to the screen reader through aria-live or role=“alert”.
Pro-tip: be careful when implementing this in your site or app. It’s very easy to get multiple announcers on the page that could announce over each other at any given time. I recommend having one announcer component that serves the entire application. That way there can only be one announcement at a given time.
\nYou can read the reasoning for it and many more details here.
\nThere are five new success criteria for level AAA, which is the highest conformance you can achieve. The new success criteria are:
\nLevel AAA is the least common level of conformance but I still think there are success criteria here that should be implemented. Things like re-auth, timeouts, and target size aren’t that hard to implement and probably are already implemented in your app since these are solid UX patterns.
\nThis success criterion looks hard to implement properly. The intent is for your site or app to support personalization and preferences. Here are the examples they give in the understanding document:
\nYou can see how this one might be pretty hard to do right.
\nYou can read the reasoning for it and many more details here.
\nWhen an authenticated session expires, the user can continue the activity without loss of data after re-authenticating.
\nYou can read the reasoning for it and many more details here.
\nIf there is a timeout present on the page, there should be a warning shown before the session ends. You should provide a warning for anything that might cause data loss due to the session ending.
\nThese are usually implemented with a modal that pops up warning you that time is running out. Make sure that modal is accessibile too!
\nYou can read the reasoning for it and many more details here.
\nIf you have animations on your site the user should able to be disable them. Unless they are essential. What WCAG defines as an “essential” animation:
\n\n\nA web application provides a feature to author animated sequences. As part of this tool, the author needs to preview the animation.
\n
You can read the reasoning for it and many more details here.
\nThe target size of pointer inputs (mouse, pen, touch contact) should be a minimum 44px by 44px unless:
You can read the reasoning for it and many more details here.
\nI really like this addition to WCAG. This success criterion says you should make sure your content can be interacted with through different modes of input.
\nThe easiest example to give would be making sure your site or app works if someone pairs a wireless keyboard to their phone to navigate. Another example would be making sure your site can be interacted with from a laptop with a touchscreen. This exact example came up on Twitter over the weekend too!
\nI like this one because my mom is 100% blind and uses her iPhone with a keyboard a lot of the time. It’s just easier than swiping sometimes.
\nYou can read the reasoning for it and many more details here.
\nWhew! That was a lot to unpack. One of the biggest struggles I had when getting started in accessibility was finding resources that digested the WCAG spec into more concrete examples. Jumping right into specifications as a first step can be daunting. With that said I hope this post was enough for you to get familiar with the changes to WCAG and what they mean in simple terms.
\nI think it is worthwhile for you to spend some time reading through a couple of the documents that explain the reasoning for these success criteria. One of the realizations I’ve had when reading through the spec is WCAG is a set of guidelines for improving your site’s UX. Accessibility really is all about making sure your site or app can be used by anyone, which serves as an excellent foundation to build upon for your site’s UX.
\nIf you or your team need any help getting up to speed with WCAG 2.1 reach out to us! If you would like to ask any questions or continue this conversation feel free to reach out to me on Twitter.
","frontmatter":{"date":"July 14, 2018","description":"WCAG 2.1 has officially been put in place as a standard but what does that mean? What was added? How does this impact my site or app? In this post we break down everything new in WCAG 2.1 and put in simple terms so you can walk away armed with the knowledge of making your site more accessibile.","tags":["accessibility","web standards"],"img":{"childImageSharp":{"fixed":{"src":"/static/7e5c20fcd943e76e94d77a4566eaa74d/a7715/2018-06-14-what-is-new-in-wcag-2-1_wcag-2-1-image.jpg"}}}}}}},"pageContext":{"id":"f910242b-16fc-5857-9edc-3790ff2fb6d4"}}, "staticQueryHashes": ["1241260443"]}