Accessibility Lessons Learned

Accessibility Lessons Learned: Building for Everyone

The ad is a reminder that the experience of people with disabilities is as much a product of the choices that were made when building the environment that they live in as it is of their physical life situation. It is also a reminder of our responsibility when building the digital equivalent of the world we all inhabit to consider people of different backgrounds and abilities.

Globally, it is estimated that 1.3 billion people live with a disability. In Australia, 5.5 million people (21.4 % of the population) live with a disability. In addition to those living with a permanent disability, many people will experience a temporary disability due to injury or illness during their lifetime. The Disability Discrimination Act of 1992 mandates equal access to premises, services and digital platforms. Digital accessibility for government services must meet WCAG 2.1 Level AA standard. 

Businesses and employers are required to make reasonable adjustments to their services, policies, practices and environment to enable access for people with disabilities. They may be exempt from making these adjustments if doing so would cause “unjustifiable hardship”, but they must demonstrate this hardship to justify not making the changes. 

Simple examples of accessibility affordances in software systems are alternative text for images, support for keyboard navigation, high contrast modes and resizable text. Achieving AA and AAA WCAG 2.1 compliance across many screens is not easily done, and even simple-sounding statements like “support for keyboard navigation” can be surprisingly hard to achieve. 



From Theory to Practice: What We Learned

Some of our PZ teams have recently been involved in a large public-facing web system which required WCAG 2.1 AA compliance. Here are some of the lessons the teams learned along the way. 



Securing Buy-in & Managing Expectations

Firstly, get company buy-in and educate stakeholders on the what and the why of investing in an accessible product. Progress initially will likely be slow with a steep learning curve, so it is wise to set this expectation up-front. Depending on the organisation’s culture getting buy-in may be the most difficult step, or it may already be accepted that a11y is a requirement for the product. 

The Retrofit Strategy: Start Small

Depending on the complexity of your app(s) and their age, it can be very time-consuming (and in turn expensive) to retrofit an AA standard. Start small and set achievable goals - a 6-month a11y-only project will burn everyone out. Striving for AAA (the gold standard) in an app that's never had A11Y considered is a stretch made exponentially harder depending on its age and complexity. Consider focusing on achieving A standard as a bare minimum, and from there, slowly work towards AA standard, juggling in feature work (shifting a11y left as part of that process) while retrofitting a11y to existing features.

Consider prioritising specific aspects of your app based on what criteria make sense, i.e. if Google Analytics shows users spend the majority of their time filling out a Contact Us form, it makes sense to focus on that rather than a Terms and Conditions page no one reads. 

Shift Left on A11y (Design First)

Avoid leaving accessibility as a single person or team’s responsibility. Starting early, considering a11y from the get-go will likely change how you build your app. It is usually much more difficult to retrofit a11y on to an existing design made without a11y in mind than to bake it in from the start.

An example of this could be designing form component error messages. Waiting until a user loses focus on a control to display an error seems optimal as you're not running the validation logic more than is required. With that said, how would a visually impaired user see/hear that error? Screen readers announce descriptive information about the elements/controls currently focused (or virtually focused in the case of mobile screen readers), so by running validation after focus has been lost, the error message will not be announced and the user may not know there's a problem until they attempt to submit the form!

Discussing the design/challenges with team members improves the understanding of everyone involved on what we're trying to achieve and why, which builds a better product and means the knowledge is shared from the initial design all the way to Quality Assurance before the product/component is shipped to users. These learnings will then be applied going forward, and just like that, we've shifted left on accessibility!

Automation vs. Manual Testing

Use automated tools; especially if you don't have a dedicated design team, but keep in mind most of the functional behaviour can only be tested manually. Physical device testing is significantly faster.

The Reality of Emulators

Emulators, while convenient, do not accurately reflect how a device functions. It's an investment but the time saved not dealing with emulators and their unreliable results pays for itself - there is no substitute for physical devices.

Screen Readers: A Steep but Necessary Learning Curve

Understanding and learning the basics of the screen readers you plan to support greatly streamlines the process and eases a lot of the initial frustrations that come with learning new software. At first, trying to remember mobile swipe gestures for both VoiceOver and TalkBack can be daunting, but you'll very quickly pick up the basics needed to navigate and interact with your application.

VoiceOver Quirks: iOS vs. Safari vs. Chrome

VoiceOver for iPhone and iPads functions very differently as does VoiceOver on Safari vs VoiceOver on Chrome, don't assume if it works on one it works on the other - you'll be surprised just how different they are. It's very easy to have regressions creeping in as changes conflict between screen readers, and fixes for one screen reader will break another.

Setting a Testing Baseline

For all parties involved in developing/testing, set baseline configuration for your supported device configuration (most likely the default config). Screen readers are highly configurable, and users have tailored their devices to best suit their needs, but catering to all these options just isn't feasible.

An example of this would be NVDAs Browse and Focus modes, where the former is used for easily navigating around a webpage's content and the latter for interacting with different elements/controls. These modes are automatically toggled by default depending on the webpage content, but it's possible to override this behaviour to trigger manually. As you could imagine, the user experience between the modes is vastly different, which during QA could result in a lot of bugs being raised if a baseline configuration hasn’t been agreed upon.



Vet Your 3rd Party Libraries

Check libraries thoroughly if leveraging 3rd-party components. Unfortunately, millions of downloads a week doesn't mean they're accessible and quite often less well-known downloaded libraries have better accessibility.

If you’re considering building your own components, WCAG provides excellent vanilla JavaScript and HTML implementations of standard components a typical site needs, however their examples attach a large number of event listeners to the DOM's body which can degrade performance, so keep that in mind. See what other websites/design systems are doing (see links to these below) and use these for inspiration/guidance where WCAG components may fall short.

Conclusion: A Reward Worth the Effort

Building an accessible app or site is a moral and often legal requirement. It requires commitment from the team and stakeholder buy-in. Our teams that have worked on projects with a strong commitment in this area have found it very rewarding, knowing that their work will be available to the broadest range of people possible.



Accessibility Resources Toolkit

Guides & Standards:

• MDN Web Docs: Accessibility Fundamentals
• W3C Standards: WCAG 2.1 Overview
• Quick Reference: WCAG in Plain English

Component Libraries We Recommend:

• Adobe: React Aria
• HashiCorp: Helios Design System