When I speak to our school website customers, I describe WCAG (Web Content Accessibility Guidelines) as a living, breathing specification. These guidelines, which help web developers optimally create and arrange web pages for those with disabilities, now has WCAG 2.1 updates, with most of the new criteria designed to address the increasing number of mobile web users.
But as is the case with most technologies, requirements and capabilities evolve. We’ve addressed WCAG 2.0 in previous articles, but just like any other specification, WCAG 2.0 is subject to change and improvement. Enter WCAG 2.1 updates.
All told, there are 17 criteria that are part of the new update. These are important considerations for you and your website provider to incorporate into your school website content management. For some of you, this overview may be too deep of a drill down. For others, it may not be deep enough. To learn more detail, jump to the W3C website for the original language.
Assisting web users with disabilities
Assistive technology (AT) is defined as any item that can help people with disabilities perform functions that might otherwise be difficult or impossible. AT can take the form of a screen reader for a vision- or hearing-impaired user; browser extensions can allow a user to crank up the size of the text on a screen, or even flatten or normalize the colors with the click of a button.
Your school community has many users that need some assistance with accessing web content. Close to 20 percent of your students, parents, staff and others in your community have some sort of physical or mental disability that sometimes creates barriers.
If you stop to think about it, mobile phones and tablets are like AT devices. Mobile devices need to be factored into the bigger picture of how content can be more accessible. And because we should all be creating content in a way that is expected and predictable, we have to all agree on some standards. Thus the new WCAG 2.1 update.
A little WCAG history
WCAG 1.0 emerged in 1999 and established 14 guidelines that had prioritized checkpoints. Whether or not a web page was accessible could be determined by checking its conformance with the checkpoints. While this was a step in a positive direction for web accessibility, there were still limitations in the way web pages were created.
WCAG 2.0 emerged in 2008, and it completely replaced the 1.0 specification. It incorporated all the original goals of WCAG 1.0, but established four core principles that content should consider. Content must be Perceivable, Operable, Understandable and Robust. Beneath the core principles are 12 guidelines that provide the goals used to create web content that is more usable to web users with varying disabilities.
WCAG 2.1 was published in June of 2018 and is an extension of WCAG 2.0. In addition to helping users with cognitive or learning disabilities and users with low vision, 2.1 focuses mostly on users with disabilities on mobile devices. With the number of mobile users continuing to be on the rise, this update was necessary to ensure websites are optimized for mobile phone usability.
New success criteria for input mechanisms
If your website complies with the new WCAG 2.1 specification, then it’s backward compatible with 2.0. If your site is not up to speed with 2.1, fear not (see living, breathing specification) it’ll get there sooner or later.
The WCAG 2.1 provides a single new guideline – Input Mechanisms – and 17 new success criteria to better address some of the needs of people with disabilities accessing web content on mobile devices. The 17 new standards in WCAG 2.1 are summarized below. I’ve organized it according to WCAG’s four principles. Also, each criteria heading is linked to W3C site, the ultimate authority on all things web accessible.
1.3.4 Orientation (AA)
Websites should support both landscape and portrait display orientations, and not be restricted to a single orientation. Some users cannot rotate their device or could be limited to one display mode or the other. Let a user choose which mode to use. This standard applies to mobile phones.
Assistive technology must be able to determine what the user is expected to enter in a field, or what the meaning of the information entered is. Help users understand and recognize what they need to do by helping them better recognize and understand the intention of form inputs.
1.3.6 Identify Purpose (AAA)
Helps assistive technologies understand what a component function does. Some users with disabilities use systems of symbols and icons to communicate. By marking up web content accurate, screen readers can translate it into symbols and icons that are understood by those users. Readers must be able to identify the purpose of interface components, icons, and sections. For example, if a button links back to the home page, the HTML markup should define the button as a “home button” and not just a button.
1.4.10 Reflow (AA)
This guideline is for users’ mobile experience. By requiring a 320-pixel fit, you ensure your website is mobile-friendly. Content should be designed to scroll vertically without making the user scroll horizontally. It helps users with visual disabilities zoom into content (up to 400%) while allowing the content to “reflow.” Content should wrap within the available viewport so that it’s always completely visible.
We’ve focused on the contrast between text over different backgrounds, but this guideline addresses contrast with non-text content. Things such as boundaries on form input fields or icons need enough contrast in color to allow users to properly perceive the content. Active interface components must have a contrast ratio of 3:1.
1.4.12 Text Spacing (AA)
Users must be able to increase/decrease the distance between paragraphs, rows, words, and characters while ensuring content remains complete and understandable. This keeps text content easier to understand for those with certain types of vision or cognitive impairments. This guideline helps avoid text overlap or buttons being moved to places where the user can no longer interact with them.
This guideline covers things like tooltips or submenus that appear on hover or when given focus. It also ensures content that appears as the result of a hover or keyboard focus action by the user can be controlled by the user. They must be able to perceive the content in order to:
- Dismiss the content at will without using the mouse or keyboard focus
- Move their mouse over the content without it disappearing
This guideline is for users with dexterity challenges who may accidentally press wrong keys.
This criterion gives all users the option to turn off single character key shortcuts, or allow a way of reconfiguring the shortcuts in their reader to suit them. If a website supports keyboard shortcuts that use a letter, punctuation, number or symbol characters, then at least one of the following must be true:
- The shortcut can be disabled
- The shortcut can be changed to use non-printable keyboard characters (i.e. Command, Option, Control or ALT)
- The shortcut for a component is only active when it has focus
2.2.6 Timeouts (AAA)
People with low vision or cognitive impairments may need more time than others to complete an action, such as fill out an online form. If it is necessary to impose a time limit, then give the user as much time as possible. Advise them how much time they have and what happens if they run out of time. Even better, tell them how they can save the data they’ve entered thus far.
This guideline is for people with disorders ranging from dizziness, nausea, and migraines caused by non-essential movement. Users should be allowed to turn off animations unless the animation is essential to what is being conveyed. Users should be able to stop or pause any content that moves or blinks.
This requirement applies to web content that interprets pointer actions and improves accessibility for users with limited motor skills. Touchscreens have brought on new sets of user interactions that include; pinching, zooming, double- or triple-fingered swiping and other gestures that may be difficult for some users. Complex actions such as pinching for zooming or swiping should also be able to be performed through simpler actions, i.e. like a tap or long-press. A good example is an online map that can usually be zoomed by pinching or moved by swiping, but also by pressing the + and - keys.
People with certain disabilities can be more likely to unintentionally click or tap a target, so it’s essential to provide a way for the user to cancel an action, by moving their pointer (cursor or finger) away from the target area before releasing. This guideline helps users cancel an action if they accidentally did the wrong thing. This criterion helps users with visual disabilities, cognitive limitations, and motor impairments.
Visible labels text on the website (clickable link) must match the accessible name (or programmatic label.) Speech input users can navigate by speaking the visible text seen in menus, links and buttons on a website. This criterion requires that visible labels match accessible labels so that users understand where a link takes them.
Mobile devices offer actions that can be completed by a motion (e.g., shaking, rotating). If your interface has such functions, the actions also need to be made available through a keyboard interface or voice-input. This “sensor-based” functionality may not be available to those whose devices are kept in a fixed position or if the user is physically incapable.
2.5.5 Target Size (AAA)
Targets for specific actions should be large to be activated by those with limited dexterity, larger fingers, limited motor skills or low vision. Generally, any clickable element must be at least 44 by 44 pixels. Minimum sizes are specified on W3C using the link above.
Users should be offered the ability to switch between different input mechanisms on their device, such as a stylus, touch input, or voice input. If an interface can be controlled using voice, the user should be free to choose voice-input instead. This requirement allows a user to choose to interact with web content via a non-default mechanism while the default might be inaccessible for them.
Give all users access to information conveyed in status messages that provide context for information displayed on a webpage in a way that can be programmatically determined and conveyed via assistive technology. An example is when a user conducts a staff directory search: the status message indicating the number of results returned may be evident to a sighted user but could require specific markup to be read out loud by a screen reader.
WCAG 2.1: a living, breathing specification
Remember now, the WCAG 2.1 Guidelines are a living, breathing specification. It is changing to keep pace with rapidly changing web technologies and the way we all – not just those with disabilities – consume content across the internet. As tools, programs, and the internet at large grows and matures, specifications are subject to change.
If you and your school website provider are now just understanding what WCAG 2.0 is all about and now this curve comes down the pike, don’t get frustrated. Take time to learn to begin understanding the WCAG principles, guidelines, features and criteria are all about, and work with your website provider to make and keep your website ADA compliant and accessible. They should help you stay current, and may even be able to take care of most of it for you with managed website accessibility services.
More important, be certain you have a web accessibility policy and program in place at your school – sooner than later. Those elements will serve as a good, solid, foundation as you try to keep up with WCAG 2.1 and that next big change in school website legal guidelines.
Related articles and resources:
About the author
Jason Morgan is co-founder and chief product officer for Campus Suite. He and his staff have guided thousands of school administrators through the process of building and launching accessible websites that engage their school communities.