Think of the most horribly disorganized, long-winded site or app you’ve used recently. For users with disabilities, that’s every page that doesn’t have the correct best practices in place for page structure, but times 1,000. If a page is difficult to use for those who don’t require any assistive technology, it will be monumentally difficult to use and time-consuming for those who do. Excellent page structure is everything for those navigating with a keyboard or a screen reader.

To be useful for those with disabilities, the structure of a page and the hierarchy of elements on it must be conveyed both visually and semantically. In other words, the code used on a page should also reflect the visual structure of the page and elements within it.

The WCAG Guideline

• Guiding principle – These guidelines fall under WCAG’s principles that online content and interactions must be “adaptable” and “navigable.”

Adaptable

Guideline 1.3 requires that “information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.”

Success Criterion 1.3.1 to meet Guideline 1.3 requires providing “programmatic access to sections of a web page,” marking headings so “they can be programmatically identified,” and generally using semantic elements so content is clearly defined.

Navigable

Guideline 2.4 requires “ways to help users navigate, find content, and determine where they are.” Headings, labels, and the way you structure the page all contribute to meeting this guideline.

What It Means for Users with Disabilities

The only way for those using a screen reader to know what’s on the page and navigate to different parts of the page without having to listen to every single word is through a clear, well-organized semantic structure. People using screen readers are able to navigate through a page using a number of methods. They can jump between sections of a page using ARIA landmarks or HTML5 elements like HEADER, MAIN, and FOOTER. They can quickly skim content by using headings and subheadings to navigate and tab through links and buttons to navigate quickly through the site or application. That is, if all of these things are available to them on your site or app.

Best Practices for Code

Convey important elements on the page using appropriate HTML5 elements or ARIA landmarks. Never rely on visual cues to inform the user of a page element’s purpose. Following coding best practices will almost always result in a well-structured page. Use common sense here. If it quacks like a duck and looks like a duck, call it a duck. Do not call it anything similar or synonymous or clever, like “water chicken.”

• If a list of items is used to navigate, make sure it’s within the NAV element.
• Main navigation should appear in the HEADER element despite it not being at the top or “head” of the page.
• Lists, regardless of how they are displayed visually, should always use OL, UL, and DL elements.
• Table markup should be used for tabular information and marked appropriately when only being used for presentation purposes.
• Clickable elements should always be semantically described as links, buttons, or form controls. Using visual cues to make a traditionally non-interactive element appear clickable won’t help those using screen readers.

Best Practices for Headings

1. Assign each heading and subheading a tag, H1 through H6.
   Avoid using bolded paragraph text for smaller subheadings – screen readers do not recognize bolded text as something that indicates a navigational section. Instead, create a heading the same size and weight as your bolded text named H5 or H6.
2. Nest subheadings in order.
   Use headings and subheadings in rank order (H2, H3, H4, etc.). Headings can be reused, resetting their order, for each section or landmark on the page. Within a single section or landmark, avoid skipping headings in the order. For example, avoid placing an H4 heading immediately after an H2 heading, skipping H3 in the progression. This can be incredibly confusing for those who cannot understand your information hierarchy from visual cues.
3. Write clear, simple headings.
   Remember that your headings are serving as a navigational tool. It should be easy to understand exactly what information will be under a given heading or subheading. Once again, if it’s a duck, call it “Duck.”

Creating a Trail for Users to Follow

Want to make sure users never get lost in a digital product maze? Follow these best practices and you’ll essentially be leaving creating a clearly marked trail for them. No more guessing as to where they are or how they got there or how to get out. Your code and headings will act as sign posts leading them through your digital app or site. Your users were once lost, but now they will be found.

Next Post in This Series 
Alt = “Title for a Post That Doesn’t Actually Describe It Whatsoever”

Part of the Accessibility for Developers Whitepaper

You can download the full whitepaper from the Progress site.

All Posts in This Series 

• PDFs: The Most Difficult, Most Widespread Digital Accessibility Problem
• Forms Don’t Have to Be Fun but They Do Have to Be Accessible
• People With Disabilities Like TV and Podcasts, Too
• The Accessibility Requirement You’re Probably Failing Right Now: Focus States
• Your Color Choice Could Be Keeping Your Site or App from Digital Accessibility
• Creating Navigable Page Structures: An Accessibility Building Block
• Alt = “Title for a Post That Doesn’t Actually Describe It Whatsoever”