1.3 Three goals of a well-coded page

Web accessibility has a set of standards called the Web Content Accessibility Guidelines (WCAG 2.1). It has dozens of specifications on topics from headers and links to colors and images. To better understand the intent of these specifications, let's group them into three goals.

Goal 1: Page structure outlined

When first visiting a webpage, a reader want to quickly gain an outline of the page's purpose and content. As noted, headings can provide our users with the page headlines. Headings can also provide an outline of the content's proper order. Thus, a webpage is understandable if the page's headings, content order, and links are well written. A poorly constructed page, on the other hand, could be perceived as out of order or missing content.

Goal 2: Content meaning explained

All meaning that would be visually gained from illustrated webpages should also be readily understood by patrons using assistive technologies. As screen readers cannot "see" our photos, alternative text is needed to explain a photo's purpose and content. Similarly, warnings are often color-coded red. These warnings should be understandable as a warning even without the use of color. Incorporating best practices as you write, and a little help from our content management systems, make these tasks easier.

Goal 3: Interactive tools enabled and described

In addition to perceiving a webpage's structure and content, a person also needs to properly interact with the page. It's worth noting at this point that screen readers are most often controlled by keyboard commands. As such, we need to enable our site to be accessible by keyboard as well as by mouse or tap.

For example, a webpage may have a floating window that pops-up asking if the user wants to sign up for a newsletter. With a screen reader, mousing to the close button is not an option. If the floating window is correctly coded, the cursor will be captured so the reader can easily keyboard over to the close button. If the window is incorrectly coded, the reader could be stuck behind a window that cannot be closed.

Interactive tools also needs to be properly described. For example, if there are four tabs of content, the site needs to describe to the screen reader which of the four tabs is visible. Without this description, the screen reader simply cannot navigate these interactive features.

Fortunately, much of this functionality is built into modern website management systems such as LibGuides. However, as content creators, we need to be alert to this issue so we use these interactive elements effectively and correctly coded.