Create content that can be presented in different ways (for example simpler layout) without losing information or structure
What does this mean?
Sighted users, like myself, often use visual cues to understand how information is organized and how it should be read. But what would happen if you were unable to perceive those visual cues? The goal of this guideline is to make visual information perceptible and meaningful to those using assistive technologies.
For example, section headings usually look different than paragraph text. They’re generally larger, and sometimes have formatting differences like bolding, centre alignment, or a different font.
When building a web page, you can make text look like a heading by changing the font size and text alignment. A visual user will have no trouble using these changes to identify the headings. However, someone using a screen reader will not be able to interpret these as headings.
Don't just change the size of your heading text, centre it or make it bold! As a best practice, you should format your headings using the heading options in the WMS. This will ensure that tags - hidden pieces of information not visually available - will be added to provide information for screen reader users.
Additionally, if order of content is meaningful, then you should make sure to use an HTML structure that will communicate that order (e.g. table, ordered list). For example, a screen reader will read a column from top to bottom before moving on to the next column. If you use columns to simulate a block or table layout with rows of content (which sighted users would read from left to right), this could be very confusing for a screen reader user.
If the order of content doesn't really matter, then it's okay if different users consume things in a different order.
Lastly, ensuring that information is adaptable means that you aren’t relying exclusively on visual cues to communicate information (e.g. a title shown in red means one thing, the same title in green means something else). Use of colour and shape can enhance ability to perceive information, but it shouldn’t be the only indication.
What to do
This list is not exhaustive, but highlights some key situations when these guidelines can be applied:
- Forms with required fields: Use an asterisk (*) to indicate required fields and include the instructions “all required fields are marked with an asterisk (*)”. In the WMS, an asterisk is automatically added to all required fields. Additionally, you could add the text “required” to the required fields' labels.
- Tables: Tables should only be used to display text data. Table headers need to be tagged properly. You can read more about what this means and how to do it well in the resource section below.
- Documents: Use existing heading and list formatting options in the WYSIWYG, so that these elements are tagged appropriately for screen readers.
- Buttons: Use real buttons with clear, informative labels and pay attention to your formatting. If the button needs to be read in sequence with another piece of content - e.g., a "learn more" button that belongs to a teaser - then you'll want to keep the button and related content in the same column, div, or block. (And remember, you should never use a linked image to simulate a button - use a ghost button instead.)
Accessibility Advisor’s Suggested Resources
Implementing these guidelines in websites at McGill may require some knowledge of HTML programming. Here are a few technical resources that can help brush up your skills in this area:
- Criteria for WCAG 2.0 1.3 Adaptable: this site outlines the full set of success and failure criteria for this 1.3 guideline. It has way more information than what I've included in this article, and would be worth consulting if you are a programmer.
- Building accessible tables: This web accessibility tutorial by W3C guides you through what HTML needs to be included when building tables, so that headers are appropriately tagged and read in the correct order by a screen reader.
- The University of Washington has a helpful overview of document accessibility. You can build on this knowledge using Microsoft's tutorial on creating accessible Word documents
- Drupal, McGill’s Web Management System, has information on accessible forms. I also recommend WebAIM’s Creating Accessible Forms article.
Rachel Desjourdy is the Accessibility Advisor in the Office of the Provost and Vice-Principal (Academic). She is available to support the McGill community in becoming more inclusive and accessible, and welcomes questions and feedback at rachel.desjourdy [at] mcgill.ca.
