Universal Design for the Web
What Universal Design Means
Universal design is a broader concept than accessible design for people with disabilities. It aims to create products and environments that work well for everyone, regardless of the presence or absence of a disability.
Universal design is proactive, benefiting a wide range of users from the start. In contrast, accommodations are reactive — specific changes made to meet the needs of individuals with disabilities.
There’s a lot to be excited about with universal design. Its benefits reach far beyond a single group, making it more inclusive and impactful. Why design for only part of the population when you can design for all? Sometimes universal design is straightforward and sometimes it’s complex, but it consistently encourages new ways of thinking about design and its users.
Learning Goals of This Section
To prepare for the web accessibility portion of the exam, be sure you can:
Identify challenges people with disabilities face while using the web.
Discuss ways in which universal design can be utilized to make web content accessible based on different types of disabilities.
In This Section:
Images
Color
Contrast
Video & Audio
Links
Headings
Keyboard Accessibility
Tables
Forms
Dynamic JavaScript
PDF Documents
Images
Don’t Assume Everyone Can See Images
Alternative Text
Provide short, meaningful alt text that serves as an effective replacement for the image for people who can’t see it.
Blind users can’t see images, and screen readers can’t interpret images on their own; they can only read text. That’s why every image on a web page needs a text alternative, provided through the alt attribute.
Alt text is usually invisible to sighted users, but it serves two purposes:
If an image fails to load, the alt text is displayed in its place.
For blind users, screen readers read the alt text aloud, or it can be rendered on a braille display.
Providing meaningful alt text ensures that images communicate their purpose to all users.
Good Example
When a screen reader comes to an image, it says “graphic”, then reads the alt text for the image. For example, when a screen reader comes across the image below, it will say:
"Graphic, An ancient cave painting in France showing two deer with antlers, plump bodies, and small legs. One deer appears to be fallen over or dead".
Alt text isn’t visible on the page itself, but screen readers can read it aloud, making the image accessible to users who can’t see it.
An ancient cave painting in France showing two deer with antlers, plump bodies, and small legs. One deer appears to be fallen over or dead
The image with alt text looks like this in the source code:
<img src="cave-painting.png" alt="An ancient cave painting in France showing two deer with antlers, plump bodies, and small legs. One deer appears to be fallen over or dead" width="503" height="346">
If an image doesn’t have alt text, screen readers won’t know what to say. They may skip the image entirely or try to read surrounding information, like the file name or the link destination. This often results in confusing output, like DSC800031.jpg or index.php?v=5&token=JD5050, which isn’t helpful.
Clear, intentional alt text is always better than leaving a screen reader to guess. Quality alt text can take a bit of thought, but the rule is simple: every image should either include meaningful alt text or be marked in the code so screen readers ignore it (which is appropriate for images that don’t add meaning to the page).
Color
Don’t Assume Everyone Can See Colors
Don’t Rely on Color Alone
Don’t rely on color alone to convey meaning. Always supplement color-code information with text explanations.
Many sighted people think of themselves as “visual learners,” so it’s natural to use color to highlight or explain information. But not everyone can perceive colors the same way.
People who are completely blind cannot see any colors.
People with low vision may see some colors, but distinguishing them can be difficult.
People with color blindness may see most colors but struggle with certain combinations, like red and green.
To make content accessible, always provide text or other cues in addition to color.
Bad Example
In this grammar lesson example, words are color-coded to show parts of speech. While this may help sighted readers, screen readers won’t convey the colors. Users relying on screen readers will hear the words, but they won’t know which colors are used.
Color codes:
Magenta = indefinite article
Teal = definite article
Blue = subject
Red = verb
Green = direct object
Purple = indirect object
Orange = adjective
Example 1: The bird carried the twig to the nest.
Example 2: The big dog ate my homework.
Example 3: Daniel sculpted a mysterious creature.
Contrast
Don’t Assume Everyone Has Perfect Vision
Ensure Sufficient Contrast
Ensure the contrast of the text against the background is sufficient to allow the text to be read easily.
Some people with low vision may struggle to read text if there isn’t enough contrast between the text and background. You don’t always need extreme contrast like black on white, but the colors should be clear enough to make reading easy.
Good Example
This text is easy to read because it is the highest contrast possible: black against white.
Bad Example
The text below says “This text is harder to read because it is gray on gray.”
This text is harder to read because it is gray on gray.
Video & Audio
Don’t Assume Everyone Can See Video or Hear Audio
Captions, Transcripts, and Audio Descriptions
Provide synchronized captions for the deaf, synchronized audio descriptions for the blind, and a text transcript for those who are both deaf and blind.
Captions
If you can’t hear, you won’t be able to follow the video below without captions. Fortunately, this video does include captions. If they aren’t already visible, click the “CC” (Closed Caption) icon in your player to turn them on.
Media player
0:00 / 3:37Speed: 1xStopped
Video source can be found here: Accessibility Stories: Corbb opens in a new window
Transcripts
Providing a transcript is a good practice and is essential for users who are both deaf and blind. Transcripts can be converted into braille for use with a refreshable braille device.
Transcript for Video Above
Skip transcript (476 words)
Accessibility stories brought to you by Deque.
My name is Corbb, and this is my Accessibility Story. I just graduated from the George Washington University, and while I was there, I found myself the last few semesters wanting to use more screen readers or use more braille. And a lot of the resources that colleges and professors are using are not currently accessible. I would have to spend — as a blind student, I would spend $150.00 on a textbook, on a paper textbook, that I couldn’t use. We would have to spend time making that book accessible.
I am sometimes frustrated that I have to be less efficient. I can still use Facebook by zooming, for example. But I’m not able to use it as efficiently as I would like to. I find myself getting headaches in the afternoon because I’ve had to struggle to see things. I find myself working harder to do the most routine task of data entry rather than saving that extra brain power for tasks like strategic thinking and directing a vision or a mission of a company that we’re working with.
Oak Consulting Groups mostly works with nonprofits and small companies in their internal and external communications. Having an accessible Internet has been crucial for the work that we are able to do for our clients.
So much of market research is so much more accessible now because everything is one search engine away, and because I rely heavily on newspapers not just in my local area, but where my clients are located and national papers, having services like NFB Newsline that allow me to access newspapers in a way that a sighted person would. Just being able to flip through a paper very quickly and very easily, and being able to use those websites to go through the archives has really made a difference.
Web accessibility literally saved my back. I was so used to using my vision that I would zoom the computer screen and lean in to the point that I was staring at my computer all throughout college with a hunched back, and a few years ago, would have probably been sitting like this. But because I’ve been able to use braille and use the speech output from my computer through accessible websites and accessible computer programs, I can sit up straight, which is great to be able to do that in a meeting and look confident. It’s also great because it saves me some chiropractic bills when I’m able to just sit up and do my work and not focus on seeing my work, but focus on thinking and doing the work that needs to be done.
When a blind person is deciding “do I go into an exciting and fun and flexible world of starting my own business,” my advice is, go for it.
End of transcript.
Audio Descriptions
A blind person can follow a video if all important information is conveyed through sound. But for videos with visual activity that isn’t described in the dialogue, blind users won’t know what’s happening.
To make such videos accessible, provide audio descriptions—a separate narration that explains visual elements not covered in the original audio. These descriptions are spoken during brief gaps in the original dialogue or narration, so they don’t overlap with the main audio. Audio descriptions work best when users can turn them on or off, or when there is a separate version of the video with the descriptions in addition to the original.
Links
Link Destinations Should Not Be Mysterious
Link Text
Ensure the link text clearly explains the destination or purpose of the link.
Before you click the links below, can you tell where each one will take you?
Deque Home Page opens in a new window
Click here
You probably guessed that the link labeled “Deque Home Page” would take you to the Deque home page. But there’s no way to know where “click here” will take you.
Descriptive link text isn’t just a nice touch. It’s essential for accessibility.
Many screen reader users navigate by tabbing through links or opening a list of links on the page. When they do this, the screen reader reads only the link text, not the surrounding content. If links say “click here,” “more,” or other vague phrases, users can’t tell what the link does or where it leads.
Clear, specific link text helps screen reader users navigate efficiently. It also improves usability for everyone, including people with cognitive disabilities.
Headings
Headings Facilitate Navigation and Add Semantic Structure
Create an Outline with Headings
Use headings to create a clear, well-structured outline of the page. Headings organize the content and make it easier for screen reader users to navigate.
Some users can’t rely on sight to skim a page and find where the main content begins. On many sites, they have to move through navigation and other repeated elements before reaching the heart of the page. On longer pages, understanding the layout and key sections can take extra effort.
Clear, well-structured headings make a big difference. Screen readers allow users to jump from heading to heading, which makes it easier to move through the page and understand how it’s organized. Headings also help sighted users scan content quickly.
This only works when real HTML heading tags are used correctly (<h1>, <h2>, <h3>, etc.) and arranged in a logical order. Skipping heading levels, using headings just for visual styling, or leaving them out altogether makes the page harder to navigate for everyone.
Keyboard Accessibility
Not Everyone Uses a Mouse
Keyboard Access to All Functionality
Ensure that all functionality is keyboard-accessible, that the tab order is logical, and that the focus indicator is always visible to sighted keyboard users.
Keyboard Functionality
Users must be able to navigate to and operate all links, forms, and dynamic content using only a keyboard. No page or widget should depend on a mouse.
Some components, particularly more complex widgets, may require specific keys. Enter or Return should activate links, forms, and buttons. Arrow keys should allow movement between items in lists or tabs. The Space Bar should activate buttons or toggle selections. In some cases, key combinations such as Shift plus Down Arrow may be needed to select multiple items in a dropdown.
Keyboard access is a fundamental part of usable, inclusive design and should be built in from the start.
Tab Order
As you tab through the focusable elements on a page, the order should be logical. Consider whether it would still make sense if you could not see the page and could only hear the text of each element as it receives focus.
Visual Focus Indicator
Don’t forget sighted keyboard users. Not everyone who uses a keyboard is blind, and people who navigate this way need to see clearly where focus is at all times.
Most browsers display a visible focus indicator, such as a dotted or highlighted outline, as long as it has not been disabled in your styles. It should never be removed. In some browsers, including Firefox and Internet Explorer, the default indicator can be too subtle for people with low vision. You can strengthen it with CSS by adding a background color, a more prominent outline, or a clearer change in text color so the focused element is easy to identify. There are many, free color contrast analyzer tools available to help identify if two colors have sufficient contrast with one another.
Tables
Associate Data Cells with Header Cells
Data Tables
Ensure data cells are properly associated with their header cells so screen reader users can navigate tables effectively.
Tables organize data visually in rows and columns, with header cells at the top of a column or the start of a row to provide context for each data cell. Because blind users cannot see this layout, the relationship between headers and data cells must be made explicit. Without it, screen readers will read data cells without context, leaving users unsure what the content represents. Properly marked-up tables allow screen readers to announce the relevant header before each data cell, giving users the context they need to understand the information.
Good Example
In the simple table below, the headers are semantically linked to their data cells. In other words, they are not just bold text. They are properly marked up in the HTML. As screen reader users navigate the first row of data cells, the screen reader will announce the corresponding header (day of the week) before reading each data cell.
Number of candies in children’s bags, by day of the week Sunday Monday Tuesday Wednesday Thursday Friday Saturday
Jeremiah 84 78 56 42 23 15 0
Anne 125 124 112 95 95 95 80
John 53 42 21 2 0 0 0
If you read the second row of the table above with a screen reader, navigating from cell to cell, the screen reader will say:
"Jeremiah, Sunday 84, Monday 78, Tuesday 56, Wednesday 42, Thursday 23, Friday 15, Saturday 0."
If you don’t mark the headers appropriately, the screen reader will say:
"Jeremiah, 84, 78, 56, 42, 23, 15, 0."
As you move through the days of the week, it’s easy to lose track of which day corresponds to which value. Was 42 for Wednesday or Thursday? With larger or more complex tables, this becomes an even greater problem.
If you’re curious, you can use your browser’s developer tools to inspect the table and see how it’s marked up. The important parts are:
The header cells are marked with <th>.
The scope of the header cells is defined as either row or col, for column.
There are additional details to consider when coding tables for accessibility, but these are the basics.
Forms
Form Controls Need Labels
Form Labels
Every form element needs a label, and that label must be explicitly associated with the form element in the markup.
Users need to understand what each form element is for. When they encounter a text input, they should know whether to enter their name, phone number, email, or something else. Without a label, users have no guidance.
For sighted users, a visible label next to the form control, such as “Name” or “Email,” is usually sufficient. But not everyone can see the screen. To ensure screen reader users receive the same guidance, you need to add appropriate markup. The simplest way to do this is by using the
The following form element has a text label associated with the text input using the
Email:
When screen reader users move focus to this form element, they will hear “Email, text input, blank” (the word “blank” means that there is no text in the text input yet). The markup is shown below.
If you’re interested, you can use your browser’s developer tools to examine the markup of this text field.
Forms markup can get quite complex, but clear labeling is one of the core concepts.
Dynamic JavaScript
Full Accessibility of Interactive Components
Dynamic JavaScript
When building interactive features with JavaScript, make sure people can understand and use them with assistive technology and a keyboard. Clearly identify what each element is, what it does, and what state it is in, and ensure keyboard focus moves where it should as the interface updates.
At the same time, only create custom components when there is a strong reason to do so. Native HTML elements are accessible by default and usually work better with less effort, saving time and reducing complexity.
ARIA: Accessible Rich Internet Applications
In the early days of the web, dynamic content was often inaccessible to screen reader users. When something changed on the page, such as a tab being selected or a section expanding, there was no reliable way for assistive technology to be notified.
That changed with the introduction of ARIA, which stands for Accessible Rich Internet Applications. ARIA allows developers to add information behind the scenes so screen readers can understand what is happening. For example, it can signal when a tab is selected, a checkbox is checked, or a menu is expanded.
Using ARIA correctly requires care. Developers need to keep track of changes on the page and make sure the right information is communicated at the right time. It can take extra effort, but it works. ARIA makes it possible for interactive features to be understood by people who cannot see the screen, allowing web pages to communicate with screen readers in ways that were not possible before.
Controlling Keyboard Focus
Keyboard access is always important, and it becomes even more critical with interactive JavaScript. When you build custom interactions, accessibility does not happen automatically. You have to design and program it intentionally.
JavaScript gives you a lot of freedom. You can create rich, dynamic experiences, but keyboard focus will not move correctly unless you manage it. If focus is not handled carefully, users can lose their place or get stuck.
Planning keyboard support for complex widgets can take time and attention. It is essential, though. Without it, people who rely on a keyboard, whether they are blind or sighted, may not be able to use the feature at all.
PDF Documents
Make the PDF Document Accessible
Tagged PDF
To make a PDF accessible, it needs to be created in tagged PDF format and carefully structured for correct reading order, tab order, and meaningful markup. This structure is what allows a screen reader to interact with the document effectively.
Tagged PDF
You can add markup to PDF files much like you do in HTML, creating what is known as a “tagged” PDF. Text can be identified as headings, paragraphs, lists, tables, and other semantic elements. Images can include alt text, and tables can have properly marked row and column headers. Most of the key structural elements available in HTML are also available in PDFs.
To create a tagged PDF, it’s best to begin with an accessible source document in an authoring tool such as Microsoft Word or Adobe InDesign. Both programs can export to tagged PDF. In many cases, additional review and refinement are needed, and Adobe Acrobat Pro is one of the most widely used tools for checking and repairing PDF accessibility. The free Adobe Reader can open tagged PDFs, but it cannot create or edit them. While many programs can generate basic PDFs, most do not produce properly tagged files, which means accessibility must be verified and, if necessary, corrected after export.