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 maketext look like a heading by ۲ݮƵ the font size and text alignment. Avisual user will have no trouble using these changes to identifythe headings. However, someone using a screen reader will not be able to interpret these asheadings.
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 toprovide information for screen reader users.
Additionally, if order of content is meaningful, then you should make sure to usean HTML structurethat 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 fromleft 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 indicaterequired 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 existingheading 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 shouldneveruse a linked image to simulate a button - use aghost buttoninstead.)
Accessibility Advisor’s Suggested Resources
Implementing these guidelines in websites at ۲ݮƵ may require some knowledge of HTML programming. Here are a few technical resources that can help brush up your skills in this area:
- : 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.
- : This web accessibility tutorial by W3C guides you through what HTML needs to be included when buildingtables, so that headers are appropriately tagged and read in the correct order by a screen reader.
- The University of Washington has a helpful . You can build on this knowledge using Microsoft's tutorial on
- Drupal, ۲ݮƵ’s Web Management System, has information on . I also recommend article.
Rachel Desjourdy is the Accessibility Advisor in the Office of the Provost and Vice-Principal (Academic). She is available to support the ۲ݮƵ community in becoming more inclusive and accessible, and welcomes questions and feedback at rachel.desjourdy [at] mcgill.ca.