If there’s one thing that’s clear to anyone involved in the technology sector, it’s that regulation falls far behind innovation. Digital accessibility policy is no better in that regard.
Accessibility features have been available on mobile devices since 2009. Apple’s VoiceOver feature was a game changer for many; opening up the mobile ecosystem that was otherwise unavailable to people with limited or no sight. Yet here we are, more than a decade later, and federal accessibility guidelines still don’t require mobile device considerations.
That doesn’t mean the guidelines don’t exist. The W3C (World Wide Web Consortium) finalized version 2.1 of the Web Content Accessibility Guidelines in June 2018. Known within the industry as WCAG 2.1, these guidelines serve as a valuable manual for how to make digital services accessible to more people. While federal law mandates compliance with WCAG 2.0 (first published in 2008), WCAG 2.1 guidelines provide a clearer map for how to meet people where they are now.
When policy doesn’t reflect the need, we need to stay ahead of the curve. We know we need to build digital services holistically and inclusively to make them available to the largest possible number of people, regardless where the compliance bar is set. We need to stop focusing on compliance, and move on to providing accessibility beyond compliance.
The need for mobile accessibility
If you’re involved in building or procuring technology solutions, you’re most likely considering how people experience your product or service from a mobile device — whether from a native app, a web app, or SMS notifications. Currently, an estimated 52 million U.S. web users are mobile-only. That’s approx 15% of the public who may not own or use a computer, but they have a mobile device that brings them to this side of the digital divide. Mobile access, then, is critical to meeting people where they are.
Mobile access becomes even more critical when we consider the information and services the federal government provides. According to Analytics.usa.gov, more than 55% of visits to U.S. federal websites in the past 90 days were from a mobile device. That’s more than 3.76 billion visits to government information or services from a phone!
Now let’s talk a little bit more about what we mean when we say “mobile access.” Not everyone accesses their information in the same way. The world is full of people with varying needs and methods of tapping into information and services — be it with voice assistance, visual assistance, or other assistive devices. And anyone who has tried to make a phone call from a cellular dead zone knows how a slow data or wifi connection can affect your ability to get the information or services you need. So there are a lot of different factors and considerations to keep in mind when we talk about mobile accessibility. Your experience with a mobile device is just one of many. When we consider that 40% of Veterans identify as having a disability, it’s fair to say that many people are accessing government services with different needs and experiences.
At Ad Hoc, we’re committed to developing services based on user needs — what they need now, and with our sights set on what regulations we know are coming in the future. We’re not the only ones. Even the White House recognizes the need to exceed policy guidelines, and has committed to WCAG 2.1 for Whitehouse.gov. Per their accessibility statement:
Our ongoing accessibility effort works towards conforming to the Web Content Accessibility Guidelines (WCAG) version 2.1, level AA criteria. These guidelines not only help make web content accessible to users with sensory, cognitive and mobility disabilities, but ultimately to all users, regardless of ability.
What’s new in WCAG 2.1
WCAG 2.1 is focused in part on improving the user experience for mobile users and for those with cognitive impairments. There are 17 new success criteria that have an emphasis on visual design criteria, plain language, and device support. Some highlights include:
Orientation
Content on the screen should be viewable in any screen orientation — both portrait or landscape on a mobile device, for example — unless the function of the application requires a certain orientation. That means if it’s easier for someone to view information on their mobile device landscape mode, they should have that option, and content should re-flow responsively regardless of device width. With few exceptions, an app or site that either only works in portrait mode or only works in landscape mode would violate this requirement. (Success Criterion 1.3.4 Orientation)
Text spacing
This criteria specifies that if someone resizes the text and increases line spacing for themselves (using the browser’s built-in capabilities or their own plugin), all the content should still be visible and functions should still be available. Once again, this points to a need to design digital tools that don’t require a static, constrained layout, but rather can reflow to meet the needs of the audience. (Success Criterion 1.4.12 Text Spacing)
Content on hover or focus
This one is a bit trickier to explain, but we’ve all experienced what should not happen. Basically, if you hover your mouse pointer or tap a screen on something to show something new on a screen (like a drop-down menu, an info box, zoom in of a picture, etc.) that additional content should stay on the screen until you choose to close or dismiss it. It shouldn’t disappear again just because you moved your mouse cursor or tapped the text on the screen. (Success Criterion 1.4.13 Content on Hover or Focus)
Input assistance
A series of input assistance guidelines to make sure filling out forms online is intuitive and clear — such as requiring that all text fields have labels that clearly identify what belongs in the field (criterion 3.3.2), and including markup that will enable a device’s autocomplete capabilities to make form filling easier (1.3.5). There’s also guidance to help people who run into errors submitting a form: making sure errors are marked and described using text, not just with a red outline or an alert icon (criterion 3.3.1), suggesting an expected response to that error if a suggestion is known (3.3.3), and provide checks to critical legal, financial, or personal data to protect against errors or misuse (3.3.4). (Guideline 3.3 Input Assistance)
What does this mean for me?
That depends on your role. If you’re part of a team building digital products, it’s time to take some training to learn how to improve the accessibility of your products. Regardless of your role on the team, accessibility is everyone’s job. What you do to ensure inclusive products will differ depending on whether you’re designing, developing, or managing the product, but you still have a role to play.
If you’re involved in procuring digital services, on the other hand, you can start by baking the requirements into your requests for proposals (RFPs) and hire teams that demonstrate experience in and commitment to building products and services aimed to meet or exceed WCAG 2.1. Make sure your team plans for and builds in automated accessibility checks, updates design system elements to meet WCAG 2.1, and implements training for the whole team to level up. Keep in mind that there are many accessibility issues that an automated test won’t catch. It’s also crucial to supplement the build/test process with accessibility experts who are trained in industry standards, including and surpassing WCAG 2.1, and who can provide expert guidance to their peers on how to address issues.
Make sure your teams know that you value accessibility beyond compliance, and support the time and effort it takes to build that into your products. Remember, it’s much easier to build something right the first time, than to try to fix it later on.
What we’re doing at Ad Hoc
At Ad Hoc, we’re talking with many of our federal customers about how they can improve the accessibility of their tools and services. This includes setting and communicating expectations for teams to build and test against WCAG 2.1 guidelines, training teams, updating design system elements, improving success criteria, and building in new automated tests.
WCAG 2.1 opens the door for other improvements as well, such as an increased focus on performance, security, and plain language. We’re focused on “shifting left” — working with customers to improve their full product lifecycle to consider security, performance, and accessibility best practices across all stages of development, not just as a compliance checkbox at the end.
Last year, we launched an internal opt-in Accessibility Champions training program to help teammates across all disciplines (product, design, research, and engineering) level up on their accessibility skills. This year we’re updating that training to make it public, so we can share it with our customers and vendor partners. We plan to update that training to include WCAG 2.1 guidance as well, create cohorts of teams to go through training together, and further institutionalize our accessibility practices.
Let’s not sugar coat this. It’s not easy to build inclusive products. It requires an understanding of a range of needs, how our work impacts those needs, and a level of empathy for the experience of others. We prioritize it because it’s important, not because it’s easy. Additionally, the responsibility to build inclusive, accessible products is everyone’s job. We all have a part to play in building products and services that meet the needs of the people we serve. If you’ve read this far, you’re already part of the solution, and together we can continue to build the right things in the right way to meet people’s needs and improve lives.
