Tips and Tricks
Accessibility: Form Follows Function
Web architecture is a lot like building architecture. Everything is designed with a purpose in mind, a meaning.
For example, if you are standing at the elevator, and you push the elevator button that shows a down arrow, what do you expect it to do? What meaning does it have?
Hopefully, it is going to come to your floor and take you to one of the floors below you.
What if it takes you up instead? What if it calls the fire department to tell them the elevator is not functioning?
These functions are not what you expect. This is an issue of semantics.
Blind users listening to a web page with a screen reader depend heavily on semantics to interpret what is on the page. When any element is misused, the meaning is altered. This confuses the user.
Most issues occur in Cascade when using the WYSIWYG (What You See Is What You Get) editor while editing a page. Let’s look at the buttons again:
Each of these buttons has a purpose in the web architecture. We’re going to focus on the buttons that specifically define the format of the content: paragraphs, headings, lists, and tables.
The most commonly misused format is the paragraph. In an attempt to make a page aesthetically perfect, paragraphs have been used to make headings, lists, and tables. Web maintainers have put spaces before, after, or in between words or characters to line up the content. Sadly, what one web maintainer sees is not what the user gets. Web browsers on different devices see this content a little bit differently, so much like not getting stressed over “small potatoes”, web maintainers should get comfortable with the “small differences.”
Let’s look at ways to resolve these bad practices.
Best Formatting Practices
Headings versus Paragraphs
On the Format dropdown menu, you see the following options we approve for use: Paragraph, Heading 2, Heading 3, Heading 4, Heading 5, Heading 6.
Paragraphs are the meat of your page. They are your ideas and thoughts in all their detail. Headings separate your ideas on the page, just like in a research paper. Like your research paper, the meaning should be concise and clear enough that if you removed all your paragraphs from your page, you would have an outline of the contents of your page, or its structure.
- Use Headings to separate ideas on a page. If someone were to scan your page, what key ideas do they get at each section?
- Use Headings in order of hierarchy. The most important content is Heading 2, the second most is Heading 3, and so forth. On most of your pages, you will start with Heading 3.
- Do not bold entire Paragraphs to emulate Headings. Bolding creates the meaning of importance, however, if everything is bolded (or deemed important), then nothing is important. Consider whether these type of Paragraphs need a style from the Styles dropdown menu instead.
Lists (Ordered and Unordered)
All lists line up thoughts in small chunks called list items. List items can have ordinal importance (e.g., steps in a procedure, top ten) or no importance (e.g., ingredients in a recipe). The former are called ordered lists while the latter are called unordered lists . Oftentimes, for aesthetic purposes, we call the unordered lists bulleted lists because some kind of graphic is used next to each list item.
- Use Lists to format content into small chunks of information. Lists are easier for a user to read than a Paragraph.
- Do not use extra characters, such as hyphens (-) or asterisks (*) to line up Lists. These characters already have separate meanings that can conflict with a blind user’s interpretation of your content (e.g., up-to-date, clear-headed, note*, 20% off*).
Tables (Tabular Data)
All tables provide data in a tabular (rows and columns) format. Tables should never be used for layout, since Web Services provides this functionality and will be happy to assist you on creative projects.
- Do not use Paragraphs to emulate Tables, either with the use of hyphens to separate the column information or spaces to line up the columns.
- Use a Table Caption (under Table Properties) instead of a Heading above a Table, since this functions as the heading of a Table.
- Use Table Headers for your Tables (under Table Cell Properties, then Cell Type) to the top row cells and/or the leftmost column cells. These provide important meaning to your data that cannot always be understood based on the content in the cells.
- Do not use Heading 1, Heading 2, Heading 3, Heading 4, Heading 5, or Heading 6 inside of a Table.
- Do not bold the header cells for your Tables in order to emulate Table Headers. Adding the extra bold provides the meaning of importance to those cells, however, they will not be mentioned again by a screen reader when a blind user is navigating the cells. Knowing the headers of rows and/or columns while navigating each cell is extremely important, and that functionality is already built into Table Headers.
Technical / Legal Stuff
- Section 508 Subpart B §1194.22 (d) - Style Sheets: Documents shall be organized so they are readable without requiring an associated style sheet.
- Section 508 Subpart B §1194.22 (g) - Table Headers: Row and column headers shall be identified for data tables.
The Web Content Accessibility Guidelines (WCAG) 2.0 makes this a little easier to understand:
- WCAG Guideline 1.3 - Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
- WCAG Guideline 2.4 - Navigable: Provide ways to help users navigate, find content, and determine where they are.
- WCAG Guideline 2.4.6 - Headings and Labels: Headings and labels describe topic or purpose