Inclusive design, as 0001.d described it, is a broad commitment, and accessibility is where it becomes concrete. Accessibility can be understood as a chain with several links. A person uses a tool, either assistive software or a feature built into a device. That tool can work only with what the author of the content has provided. Those authoring practices are collected into a technical standard, the standard is the usual benchmark for meeting a legal requirement, and checking has to confirm that the whole chain holds. If any link fails, the person at the start of the chain is shut out, so this section follows the chain link by link.

The tools people use#

A screen reader converts on-screen text and interface elements to speech or braille. It helps to picture how this differs from looking at a page. A screen reader doesn't see the visual design, so it relies on semantic structure: real headings, lists, and labels that say what each element is. Text styled to look like a heading, by enlarging and bolding it, isn't exposed as one, and unlabeled form fields are announced only as "edit text," which gives the user no idea what to enter. To know whether a product works, test by operating it with a screen reader and no mouse.

Two other tools convert between speech and writing, and the names are easy to swap. Text-to-speech reads text aloud, supporting readers with dyslexia or low vision. Speech-to-text turns speech into text, supporting those who have difficulty typing. Its accuracy can vary across accents, so check that it works for the particular student.

Many of these tools don't need to be purchased, which is worth knowing before anyone orders software. Operating systems include zoom, high-contrast and dark modes (which change display colors to fit visual needs), voice control, sticky keys (which let someone press key combinations one key at a time), and switch access, which means operating a device with simple switches, for people with limited motor control. Browsers often offer a read-aloud feature as well. Many accommodations need no added software, so check these first.

What authors have to provide#

The tools can do only so much with what they're given, so accessibility depends heavily on the people creating content, including teachers. Images are a clear example. Alternative text (alt text) is a written description that screen readers read aloud, and it should convey an image's purpose. For a chart, that's the main finding ("Bar chart: enrollment doubled from 2019 to 2024"). For a linked image, it's what the link does ("Lunch menu"). For a picture in a quiz, it's whatever a sighted student needs in order to answer. File names and "photo" don't do this. Purely decorative images should have empty alt text, so screen readers skip them and don't interrupt the reader with noise.

Video and audio raise the parallel problem for people who can't hear them, and a few formats address different needs. Captions display speech and relevant sounds, such as a warning beep, in sync with video, mainly for people who are deaf or hard of hearing. Transcripts provide the same content as separate text, which also serves deafblind users of braille displays. Audio description narrates visual content for blind viewers. Automatic captions often garble technical terms, which can change the meaning for those relying on them, so they need checking in a computer science class in particular. Features that help one group often help others, as captions help anyone in a noisy room or learning a new language.

Structure matters along with content, because screen reader users navigate by lists of links and headings. Link text should describe its destination ("Download the permission slip"), since "click here" can't be told apart from other links out of context. Heading levels should reflect structure, not desired size, because an out-of-order outline misleads anyone moving through a page by its headings. This is the same reliance on semantic structure described above, seen from the author's side.

Input is a separate concern. All functionality should work from a keyboard, without requiring a mouse or hover, for people with motor disabilities and screen reader users, who may be unable to use a pointing device. Check by moving through a page with Tab and Enter. Two failures are common: a keyboard trap, in which a user can get into a component and can't get out again without a mouse, and drag-and-drop with no alternative, so give drag-and-drop a keyboard path.

Visual presentation is the last of these authoring concerns. Don't convey information by color alone; add labels, patterns, or words, so that a student with color vision deficiency can tell which fields are required because the label says "required" and not only because it is red. Text also needs sufficient contrast with its background for people with low vision, and WCAG level AA asks for a contrast ratio of 4.5:1 for normal text.

The standard and the law#

That contrast figure comes from the standard that gathers these practices. The Web Content Accessibility Guidelines (WCAG) provide testable criteria at three levels: A, AA (the usual target), and AAA (the strictest). They are organized under four principles, abbreviated POUR, that give you a way to sort any barrier. Content must be perceivable, meaning it can be sensed, which is the concern of alt text, captions, and contrast. It must be operable, meaning it can be used, for example by keyboard. It must be understandable, which a message like "Error 0x8004" isn't, because it doesn't say what happened or how to fix it. And it must be robust, meaning it works with assistive technology and across a variety of software.

Standards are voluntary on their own, and the law is what makes equal access an obligation. Section 504 of the Rehabilitation Act and the Americans with Disabilities Act (ADA) require schools to give people with disabilities equal access, including to digital materials used in instruction, and free tools aren't exempt. WCAG is the usual technical benchmark for showing that access has been provided. Obligations don't depend on someone having complained, since retrofitting after a request can leave people without access in the meantime. When a school is choosing a product, an accessibility conformance report documents how it meets the criteria, and where a product falls short, the school still needs to provide an accessible alternative. Laws and standards thus work at different levels: the law states the requirement, and the standard says in testable terms what meeting it looks like.

Checking the result#

Testable criteria invite automated testing, which is useful within limits. Accessibility checkers such as WAVE and Lighthouse flag missing alt text and low contrast. They can't judge whether text is meaningful or a reading order makes sense, because a machine can confirm that alt text exists but not that it describes anything. A perfect score therefore doesn't prove access. Test with assistive technology and with users, and when a vendor reports a perfect score, ask for evidence of that testing too. The accessibility requirements in this section are one instance of rules that govern computing, and 0001.f takes up the wider set of laws, licenses, and policies.

• screen reader: software that converts on-screen text and interface elements to speech or braille
• semantic structure: markup that says what each element is, such as real headings, lists, and labels
• text-to-speech: reading text aloud
• speech-to-text: turning speech into text
• switch access: operating a device with simple switches
• alternative text (alt text): a written description of an image's purpose, read aloud by screen readers
• captions: speech and relevant sounds displayed in sync with video
• transcript: the same content as captions, in separate text
• audio description: narration of visual content for blind viewers
• keyboard trap: a component that a keyboard user can't move past
• Web Content Accessibility Guidelines (WCAG): testable criteria at levels A, AA, and AAA under the principles of POUR
• POUR: perceivable, operable, understandable, robust
• accessibility conformance report: a document showing how a product meets accessibility criteria
• accessibility checker: an automated tool, such as WAVE or Lighthouse, that flags issues such as missing alt text and low contrast

Practice: practice questions for 0001.e