This video, courtesy of UW DO-IT Center, emphasizes the importance of incorporating accessible documents into all course design. Documents will not need to be made accessible upon request if the work is already done upfront.
Color and Color Contrast
Having high contrast in a design is more important for users who have low vision or who are colorblind. It is essential to consider alternative means of conveying information, provide proper color contrast, and offer multiple visual cues beyond color alone.
In WCAG 2, contrast is a measure of the difference in perceived "luminance" or brightness between two colors. This brightness difference is expressed as a ratio ranging from 1:1 (e.g. white on white, lowest ratio) to 21:1 (e.g., black on a white, highest ratio). To give a frame of reference, on a white background:
- Pure red (#FF0000) has a ratio of 4:1. I am red text.
- Pure green (#00FF00) has a very low ratio of 1.4:1. I am green text.
- Pure blue (#000FF) has a contrast ratio of 8.6:1.I am blue text.
For regular text, a contrast ratio must be at least 4.5:1.
For large text, a contrast ratio can be lower than the regular text, about 3:1. WCAG defines large text as text that is 18pt and larger, or 14pt and larger if it is bold.
There are several eyedropper tools could help you to check the contrast ratio manually, such as WebAIM Contrast Checker. Or you can use a browser feature to check the contrast ratio. (The video of Topic 14/Color Contrast introduces this feature from 2'10'' to 3'10''.)
Here are some examples of text with almost exactly 4.5:1 contrast.
- Gray on white
- Purple on white
- Green on white
- Red on white
For many of us, some of these combinations are not very readable. That is why 4.5:1 is the minimum required by WCAG..
Many people with disabilities cannot use a mouse or touchpad and they must rely on their keyboard.
A user may not use a mouse because that user:
- is blind;
- has low enough vision such that they have difficulty following a mouse;
- has a motor impairment that prevents their using a mouse; or
- prefers to use a keyboard to complete certain tasks, such as filling out a form.
A well-designed page should use visual focus indicators to assist people navigate different location of the page only by using keyboard.
Ensure that all content can be accessed with the keyboard alone.
To test a page for keyboard accessibility, you can try to navigate this page only by using the keyboard. The following table includes many of the most common online interactions. You could test a page using the keystrokes in the table to evaluate keyboard accessibility.
|Navigate to interactive elements|
|Select (dropdown) menu|
|Menu bar|| |
Certain people are not able to understand the context of an image unless it is described to them.
Alternative text serves several functions:
- Screen readers announce alternative text in place of images, helping users with visual or certain cognitive disabilities perceive the content and function of the images.
- If an image fails to load or the user has blocked images, the browser will present the alternative text visually in place of the image.
- Search engines use alternative text and factor it into their assessment of the page purpose and content.
When we embed a digital image, we need to consider why an image is here and what information the reader is supposed to gain. The video will show you how to write appropriate alternative text.
Don't just describe the purpose of the image, give the information.
Some other best practices include:
- Avoid “image of”, “photo of”, etc, unless the medium is particularly important.
- Decorative images should have blank or empty alternative text
- Complex images, like charts or graphs, should have long description located near the image.
- Posters, flyers, and the like must have the same information presented in nearby text
Provide color contrast and other design elements to help color blind users
Heading structure is a wonderful thing to help screen readers to skim through the page and navigate a page according to its headings, especially for blind people.
Headings are ranked <h1> through <h6>, with the <h1> representing the most important idea on the page, and sub-sections organized with <h2> level headings. Those sub-sections can themselves be divided with <h3> level headings, and so on.
All pages should at least have a <h1> level heading giving the title of the page.
- Do not select heading levels based on their appearance. Select the appropriate heading rank in your hierarchy.
- Do not skip heading levels to be more specific (for example, do not skip from <h2> to <h5>). It is permissible to skip headings in the other direction if the outline of the page calls for it (for example, from <h5> to <h2>).
- Do not use bold instead of a heading. One of the most common accessibility mistakes is making text bold when a heading is needed. Though the text may look like a heading, the underlying code is not set correctly, and screen reader users will not benefit.
- Do not overuse headings. In most cases, content editors will not need more than <h2> rank headings and the occasional <h3> rank. Only for exceptionally long or complex pages would <h5> and <h6> be necessary.
It’s most important for link text to make sense without the surrounding sentences or content. Phrases such as "click here," "more," "click for details," and so on are ambiguous when read out of context. The link text alone should convey the function and purpose of the link. Link text should also be unique and easy to speak out loud by the screen reader software.
Consider these guidelines when writing link text:
- Avoid link text like “Click Here,” “More,” and “Read More.” These kinds of links can be confusing when a screen reader reads them out of context.
- Use unique link text where possible. Speech recognition software users may have a bad experience with duplicated link text.
- It is OK to link a full sentence, but avoid longer.
- The link together with the surrounding sentence, paragraph, or list item should be enough to convey a link’s meaning or purpose.
- A non-color indicator, such as an underline, or bold-face.
Tables naturally present some accessibility challenges. So please make sure there is no better way to present the information before using tables.
Tables without structural markup to differentiate and properly link between header and data cells, create accessibility barriers. Relying on visual cues alone is not sufficient to create an accessible table.
Accessible tables need HTML markup that indicates header cells and data cells and defines their relationship. Assistive technologies use this information to provide context to users.
Header cells must be marked up with
<th>, and data cells with
<td> to make tables accessible.
- Keep it simple: Complex tables are more work for content creators as well as being harder to interpret for users. It’s usually better to break up complex tables into simple individual tables, each containing the data for one sub-topic.
Table separation: If several tables follow one another, don’t use a single table and put in an additional row of
<th>cells. Screen readers may read aloud all
<th>cells in a column, resulting in confusion. Start a new
<table>when the topic changes.
- Data separation:
- Make sure that each separate piece of data has its cell. Don’t use headers in one column and all data in a second column, as this will make it almost impossible for screen readers to work out the relationships between data across columns.
- Styling: It is also helpful to differentiate
<td>cells visually. For example, header cells have a dark gray background.
- Color and color contrast: Make sure that the contrast ratio between the text and background is good for both headers and data cells.
- Zebra tables: It acts as a visual guide. Highlighting the cell (and row/column) on mouseover and keyboard focus to support people to see where they are.
Disability Support Services on campus provides additional information and resources on making documents accessible for all students.
"Creating Accessible Documents" by University of Washington DO-IT is licensed under CC BY 3.0
webaim.org © WebAIM
Accessibility at Yale © 2023 Yale University