Partway through World Wide Web Consortium’s Introduction to Web Accessibility course, there’s a video that depicts an alternate reality where public spaces are designed entirely for users with disabilities.
The video, taken from a 2005 ad for Electricity of France, shows individuals without visible disabilities struggling to navigate an environment not built for them. Pedestrians walking down a slick footbridge slip and slide, while peers in wheelchairs glide past. A customer at a bank can’t understand a teller’s instructions, relayed only in sign language. A library patron flips through the library’s selection of books, which are all in braille.
The video is a powerful illustration of the course’s underlying message: our design choices determine who can benefit from our products — and who can’t.
What is Web Accessibility?
The World Wide Web Consortium, or W3C, course wants developers to think about the needs of users with disabilities, rather than memorize accessibility requirements. Although there are checklists and automated tools available online to help developers design for accessibility, one of the course’s first videos features instructor Shawn Lawton Henry advising viewers against primarily learning about accessibility by reading through documentation.
“The first step is learning about how people with disabilities use the web,” Henry said.
How Do Users With Disabilities Navigate the Web?
The course pulls from W3C’s Web Content Accessibility Guidelines (WCAG), the international standard on web accessibility, and covers many of the items on its checklist, including practices such as semantic markup of HTML, ease of keyboard navigation and audio transcriptions. But designing for accessibility can be complex, and a product can still be inoperable for users with disabilities, even if it technically checks all the right boxes. Individuals have different and sometimes-conflicting needs, and it’s easy for developers to make mistakes if they’ve never seen how web design accessibility features are used in practice.
Luckily, W3C’s free online course, which launched on EdX earlier this year, is informative and enjoyable and taught by instructors with disabilities who sprinkle in demonstrations of accessibility features they themselves use.
Early in the course, instructor Anthony Vasquez demonstrates how screen readers work. A screen reader is a program that assists users who are blind or visually impaired by translating the contents of a webpage into non-visual output, usually speech.
Vasquez, who is blind, initially has his screen reader set to a high speed on his laptop in order to quickly scan through webpages. To the uninitiated, screen readers in action can sound like a blur of unintelligible sound. Vasquez slows the screen reader down several settings for the viewer, and after refreshing the page, it reads: “Seven headings and seven links. Acme Mobile Service. Heading level one: Acme Mobile Network Operator.”
“The first step is learning about how people with disabilities use the web.”
Vasquez is demonstrating that screen readers don’t only read the text content within a webpage, but the structure of a page as well. A lot of information is conveyed through a page’s layout. Most of us look at a website and understand the purpose of the site by reading the title, and subtitles and images help users understand how information is organized. All of this helps users orient themselves, decide whether to spend more time on the website, and if so, figure out where to go for the information they are looking for.
Screen readers fulfill these needs for blind and visually impaired users. The programs pull the necessary information from pages’ HTML, such as page titles and alt text labels. On Vasquez’s website, the screen reader got “Acme Mobile Service” from the page title in the HTML, which is also displayed in the webpage’s tab, and “Acme Mobile Network Operator” from the level one heading tag in the HTML.
“When there is a well-structured page that uses good headings, someone using a screen reader gets a good idea of the basic structure very quickly,” Vasquez says.
The same principle applies for mobile devices. Vasquez demonstrates how to use the screen reader for navigating around apps on his iPhone, which includes a unique “rotor” gesture that allows users to change the screen reader settings. The rotor gesture is activated by placing two fingers on the screen and rotating either counterclockwise or clockwise to choose between reading words or headings on the page. Users can either tap on the screen to hear certain parts of the page, or swipe to hear previous or next parts.
Screen readers don’t only read content and structure of web pages out loud, they can also plug into other devices, such as braille displays. These devices take input from screen readers and translate it into braille, which is communicated to the user’s fingertips through a row of rounded pins that are mechanically raised and lowered.
Accessibility Goes Beyond Screen Readers
Accessibility isn’t only about making web pages accessible for screen readers. The course also covers users who have vision impairments but who can still use their sight with accommodations, users who cannot use the mouse and users who use speech input instead of a keyboard and mouse.
Instructor Kim Patch demonstrates a few different speech input technologies in the course. One uses a numbered grid system — which Patch tapes to the side of her computer screen — to control navigation on web pages. Another method uses a mix of voice search and voice-controlled tabbing to navigate. Patch highlights ways developers can make navigation easier for speech input users, such as making whatever is currently selected on a page — also known as the “focus” — more obvious, and avoiding small dialogue boxes and dropdown menus that only display a few items at a time.
Patch said another cause of problems for speech input users is single-key shortcuts. While single-key shortcuts can be useful for keyboard users, speech input users often find that spoken words can get mistaken for single characters, triggering unexpected and unwanted actions. It’s an example of a feature that may be useful for some users while being a hindrance for others.
Instructor Henry also expands on this theme in the course. She gives the example of two types of vision impairments — low vision and tunnel vision — that need different types of accommodations. While users with low vision need screen magnification, users with tunnel vision only have a narrow field of vision, so large text would make things harder to read.
Accessibility Helps Developers Too
Accessibility discussions usually focus on front-end development, but it’s a good idea for back-end developers to be mindful of accessibility as well. Eric Bailey, who works with A11Y, an open-source site that provides accessibility resources, said many developers have disabilities, and rely on tools like screen readers. Ensuring those developers could work effectively on a development team is important.
“If you’re going to do disability work, hire people with disabilities,” he said.
Bailey pointed to Microsoft as a company that has a good track record around accessibility. The Visual Studio Code editor has “good and increasingly better support for assistive technology,” Bailey said. “The Xbox has the adaptive controller, which has been widely celebrated as a way to get people to be able to use video games. It’s interesting from that perspective because it actually opens up new revenue streams for them.”
There are also numerous companies in the accessibility space that can help perform accessibility audits, and tools online that developers can use to check against accessibility standards, such as WebAIM’s evaluation tool and A11Y’s checklist. But having a fundamental understanding of the needs of different users is possibly the most important step developers can take to make their software accessible.
More than anything else on the internet, it feels like a space where people are working every day to fulfill the technology’s vision of making the world a more democratic place.
