We’ve done a great deal of accessibility testing with users over the past few years, and have learned a lot along the way. We’ve synthesized our learnings into 5 takeaways for you to consider the next time you undertake an accessibility testing project.
1. Hearing a website is an entirely different experience
Designers and developers often don’t consider how a website might sound to someone using a screen reader. For example, an account menu that reads “Hi, Jessica!” might not mean anything to someone who can’t see there’s a down arrow beside it (the arrow won’t be read by screen readers unless developed to do so). Think of how your website will sound and how easy it will be to use without the aid of visual cues. Indicating to a screen reader through various techniques that an element is collapsed or expanded – or if a menu has submenu items – is crucial to understanding a website and what options are available. Additionally, consider your link and button labels carefully. Will someone know that “Hi, Jessica!” is an account link if they can’t see the account icon? Users using screen readers may be navigating your website based on links and buttons alone, so ensure any labels make sense out of context.
2. Organization and structure is key
Generally in testing, we’ve seen that users of assistive technology quickly overview a page first to get a sense of the structure, and then navigate to a specific piece of content – most commonly by headings. There may be users accessing your site who are unable to see the screen, may be zoomed in 800%, or may need to take cognitive breaks and therefore need a clear structured page to reduce cognitive load. Structuring and organizing your website appropriately and in an efficient manner is important for everyone. Headings are the most commonly used way of navigating – either directly through assistive technology like screen readers, or by visually scanning the page. Ensure any headings used are based on structure not aesthetics. Consider zoomed in users as well and group related content together. If an action is taken on a page, don’t make significant changes happen somewhere else on the page; zoomed in users may not know a change has happened.
3. Custom form elements aren’t worth it
Custom form elements take a lot of design and development effort in order to be made accessible. If you’ve created a custom radio button, for example, there’s no way you would ever know for sure that it was entirely accessible for the thousands of assistive technology and browser combinations that exist. We always recommend using built-in browser form elements – they’re already accessible, and will continue to be accessible as technology advances. In testing, we’ve seen participants be uncertain if custom checkboxes or radio buttons are actually interactive because they are accustomed to the visual styling of default browser form elements. Keep it simple, take out the guesswork and additional effort required to develop custom form elements, and just stick to the basics. Your users will thank you for it.
4. Typography can make or break your design
WCAG 2.0 (Web Content Accessibility Guidelines) doesn’t provide sufficient typography guidelines to make content easier to read for people with low vision. The biggest omission from WCAG 2.0 is font size. A base font size of at least 14px is good for most, but aim for higher whenever possible. WCAG 2.0 colour contrast guidelines aren’t enough either, and on several occasions we’ve heard comments during testing about text being difficult to read even though contrast standards are met. Good typography is key to good design, especially for accessibility. If you’re using lightweight fonts, stop now! Lightweight fonts, even in a large font with high colour contrast, are notoriously difficult to read and will basically disappear if viewed in a high contrast mode. Also, consider your line length (number of characters per line) and line spacing (spacing between lines of text); too much of either will make reading difficult for someone who’s zoomed in on the screen.
5. Modals (or pop-ups) are your users’ worst enemy
We’ve seen modals fail 100% of the time, one way or another, when testing with users. Most commonly, screen readers and keyboards get stuck behind modals and can’t access it’s content. If screen readers and keyboards ARE able to access modal content, focus usually can’t be contained within the modal and will extend to other sections of the page, which can be confusing for someone who can’t see what they’re interacting with. We’ve also seen issues caused for people who are zoomed in when they initiate an action that launches a modal, but the portion of the page they’re zoomed in on isn’t where the modal opens. In most cases, they’re completely unaware that a modal has even opened. Avoid modals wherever and whenever possible, and instead use other options (such as accordions) to keep content in context.
With an unlimited number of personal setups out there when it comes to assistive technology and accessibility (in fact, we’ve never run into the exact same setup more than once) it’s important to keep all users and technology in mind. Learn more about designing and developing accessible experiences, or more specifically considerations for mobile accessibility, to make sure you’re creating pleasurable digital experiences for everyone.