Is your mobile content optimized for people with disabilities? If you’re not sure, you might need some help. The good news: Digital accessibility has established rules and best practices, and by developing an accessible mindset, you can create more effective mobile content.
Published by the World Wide Web Consortium (W3C), the Web Content Accessibility Guidelines (WCAG) provide essential guidance for creating mobile websites and apps that work for everyone. The objectives of WCAG provide an excellent foundation for mobile accessibility, and the document contains numerous Success Criteria (SC) that specifically address mobile content.
However, it’s important to understand that all WCAG guidelines can apply to all digital content. The WCAG framework is built on principle-based objectives: Content must be perceivable, operable, understandable, and robust. When content meets these goals, it can be considered reasonably accessible for most audiences.
While some success criteria contain specific language geared towards website content, developers should understand the importance of the principle-based approach. We recommend reviewing WCAG in its entirety before beginning development of a mobile website or app — an accessible mindset can help your team find (and resolve) a wide range of accessibility issues.
Read: What Are the Fundamentals of Mobile Accessibility?
WCAG 2.1 has success criteria specifically intended to improve mobile experiences
Published in June 2018, WCAG 2.1 includes 17 new success criteria (in the coming months, WCAG 2.2 will become an official recommendation, and we’ve written about the upcoming changes in WCAG 2.2 in other articles). WCAG 2.1 prioritized mobile experiences, and many of the new criteria directly address the challenges of accessible mobile design.
Here’s an overview of how some of the guidelines affect mobile websites and apps:
Success Criterion 1.3.4, “Orientation"
Content does not restrict its view and operation to a single display orientation (unless that display orientation is essential).
For mobile apps and websites, this means that the content can be switched between portrait and landscape modes (and other display orientations) without losing functionality.
More Information: WCAG 2.1 - SC 1.3.4 Orientation
Success Criterion 2.5.3, “Label in Name"
For user interface components with labels that include text, the accessible name contains the text that is presented visually.
Many people use speech input to operate their mobile devices. If an app or mobile website has menus, links, and buttons, the user will expect that the accessible names of interface components match the labels — in other words, if a button says “read more,” the user will expect that they can say “read more" to activate the button.
More Information: WCAG 2.1 - SC 2.5.3 Label In Name
Success Criterion 2.5.1, “Pointer Gestures”
Check that multi-point or path-based gestures can also be operated with a single-pointer.
For example, if a website requires a user to operate a feature with a gesture (such as swiping, dragging, or pinching), the user should also have the option to use a single-pointer activation method.
This criteria helps to ensure that people with mobility-related conditions enjoy the same functionality as other users. It’s also beneficial for people who have temporary and situational disabilities (for example, a user wearing a glove might not be able to perform a complex swiping gesture to operate the app).
More Information: WCAG 2.1 - SC 2.5.1 Pointer Gestures
Success Criterion 2.5.2: “Pointer Cancellation"
Users must be able to cancel accidental triggering of functions on down-events.
When a user touches a screen or presses the button on a mouse, they trigger a “down-event.” People with motor disabilities may inadvertently trigger down-events, which can have frustrating consequences. Authors can address this problem by making activation on the up-event (when the user stops touching the screen or releases the mouse button), which gives the user an opportunity to cancel the event.
More Information: WCAG 2.1 - SC 2.5.2 Pointer Cancellation
Success Criterion 2.5.4, “Motion Actuation"
Functions operated by device motion can be disabled and have an alternative input method.
Some users may be uncomfortable performing motion gestures (such as shaking, tilting, or using gestures picked up by the device’s camera). Authors should provide alternatives wherever possible. For instance, if a mobile app allows a user to tilt their device to navigate to the next screen, the author can also provide a “next page" button that enables the user to achieve the same effect.
More Information: WCAG 2.1 - SC 2.5.4 Motion Actuation
When developing mobile content, prioritize digital accessibility
While the criteria listed above offer specific guidance for mobile design, we want to stress that WCAG 2.1 is designed as a comprehensive framework for digital accessibility — success criteria written for website content often contain important guidance for mobile content. To conform with WCAG, you’ll need to consider every success criterion, not just the criteria that apply directly to mobile design.
For instance, SC 1.1.1, “Non-text Content,” requires text alternatives for images and other non-text elements. Website developers can meet this guideline by adding image alt tags, but mobile app developers may need to employ other techniques depending on the app’s platform.
Remember, mobile accessibility isn’t optional. Content creators must provide reasonable accommodations for users, and WCAG provides useful resources for making those improvements. When mobile content is accessible, it provides a better experience for all users — which can have numerous benefits for creators.
To learn more about the principles of accessible mobile design, download our free definitive checklist for mobile accessibility.
