This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

Filtering data is a great way to give users control of the information they want to see. This helps many different types of users all at once. Sighted users have the ability to narrow down a page of data results from, for instance, 2000 results to 200 results, making it much easier to find the specific content they are looking for. Visually impaired users use filters for the same reason. Having a screen reader read out 2000 results with no way to filter can be extremely cumbersome.

It is also important to give users multiple ways to filter through. Giving users this extra mechanism over what they’re able to see helps them have a sense of control over the information they are consuming.

Waiting Spinner

Anytime the user is waiting on data to load, there needs to be a waiting spinner. Waiting spinners are a great, simple way of showing sighted users that there will be information displayed momentarily. However, screen reader users are at a disadvantage. They’re typically left in the dark on the status of their action or if it went through at all. Make sure that you use WAI-ARIA’s live regions to tell the screen reader user that everything is fine and the data will be available soon.

To make this truly inclusive, make sure the screen reader announces both when the content is loading and when it is done. For example:

<span class=”sr-only” aria-live=”assertive”>Please wait. Populating table.</span>

<span class=”sr-only” aria-live=”assertive”>Data population complete.</span>

Another helpful addition could be to add a statement with the number of entries loaded at the end of your “Data population complete.” statement.

aria-live

The aria-live attribute is used to set the priority of the live region for screen readers. aria-live can be set to off, polite, or assertive. The polite value tells the screen reader to wait until it has finished reading the rest of the page before coming back to the section that has updated. Usually, aria-live=”polite” is the best option since it reduces the chance that you’ll startle or confuse the user by interrupting the screen reader. The assertive value interrupts the screen reader’s set script of the page to alert the user to a change. When using aria-live with a waiting spinner, it is best to use the assertive value since it will immediately alert the user to the change.

To maximize browser compatibility, some accessibility experts recommend using both aria-live=”assertive” and role=”alert”. This can be problematic, according to the Mozilla Developer Network’s “ARIA Live Regions” article, as it can cause double speaking issues for VoiceOver in iOS.

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

Tables that have specified rows or columns with header information about that particular row or column is considered a data table. Without a header, a table can be considered a formatting table. Personally, I don’t like to use tables to format content, but it’s not technically wrong. In this blog post, I’ll be focusing on making data tables accessible.

General

The simpler the table, the better. Simple tables are more easily understood than ones that are more complex (i.e. have multiple table headers or sections). Simpler is always better, but necessity will dictate how simple your data tables can be. However, it is recommended that you do your best to simplify your data tables as much as possible to be understood by a broader audience.

TH and the scope attribute

Sighted users have the luxury of being able to read data tables in any orientation the data may be displayed in. Screen reader users can only hear one cell at a time from left to right, top to bottom. This can easily cause confusion, especially if the table is complex or doesn’t use the right attributes in the markup to make it accessible.

Table headings allow sighted users to designate certain table cells as headers for the column or row it belongs to.

The scope attribute is used to clarify the scope of a header cell and aid comprehension for those who use screen readers. It identifies whether the cell is a header for a row, column, group of columns, or group of rows. The scope attribute can also be used on <td> tags to denote the content of the cell is the header for a row. For example:

<table class="table table-bordered col-2-bloat">
    <thead>
        <tr>
            <th scope="col">#</th>
            <th scope="col">Address</th>
            <th scope="col">GLA</th>
            <th scope="col">Sales Price</th>
            <th scope="col">MLS Number</th>
            <th scope="col">Service</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1</td>
            <td scope="row">123 Main St</td>
            <td>0001</td>
            <td>$1,500,000</td>
            <td>q11111</td>
            <td>Desktop Appraisal</td>
        </tr>
        <tr>
            <td>2</td>
            <td scope="row">100 North St</td>
            <td>3205</td>
            <td>$580,000</td>
            <td>z00111</td>
            <td>Desktop Appraisal</td>
        </tr>
    </tbody>
</table>

Sometimes the scope may not need to be on the first element of the row. As in the example above, it would aid comprehension for the screen reader to read out the street address before every value rather than the number row it is.

Penn State’s Accessibility article titled “Tables for Data in HTML” has a great example for how table headings can aid comprehension of a visually impaired user.

Assuming the markup is correct and uses scope as we showed in the code example above, the screen reader should read out the following:

“black, Spanish: negro

black, French: noir

black, Irish: dubh

black, Welsh: du…”

This way, by the time the screen reader reads the last element of the row, the user is still able to remember what English term is being translated.

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

Why do we use an unordered list?

Using an unordered list is something that we’ve been doing since about 1997-2000 when HTML4 and XHTML were becoming standard. At this point, it’s just convention. We can style anything however we want these days, but we keep using unordered lists as navigation. In the event of a CSS failure, the navigation bar will revert back to a regular unordered list. This bulleted list of blue, underlined links is a visual indicator that this list serves some kind of navigational purpose. This way, we’re including older users, older devices, assistive technology users, and those experiencing a CSS failure all in one!

We wrap the list in a nav tag to trigger additional semantics and behaviors that allow AT users to better understand the purpose of this list of links. For example, screen reader users going through the navbar might hear “navigation landmark. List. One of five. Link: home.” It’s easy for your user to understand that they are in the navigation bar, how many links it contains, and if they want to go home, they can do so immediately after hearing the “link: home.” The nav element also automatically offers some screen reader users the ability to hit the D key and hear the list of navigation links while on any other part of the page.

More on Navigation Conventions

Although we like to make things look cool and new, sometimes it’s just best to stick with what we’ve always been doing, especially when it comes to navigation conventions. The human brain uses schemata to understand new things. This schemata acts as a cache for understanding, if you will, constituting the prior experience which the current experience is compared to. As humans, we like what’s familiar to us, so we’ll compare things to other things we’ve seen just to make sense of it.

When it comes to navigation bars, we don’t want to make our users think, which is a common idea in usability. This is why we typically see navigation bars at the top of the page with font larger than the rest of the page and different links right next to each other. It’s familiar to us. We can look at that and immediately know that this is the part of the page we need to use to be able to see other pages on this website.

Know where you are to know where you want to go

Another helpful aspect of navigation bars is when they show which page you’re on by making that navigation link or button “active.” Just like when maps in malls have the “you are here” dot, we need some visual “you are here” indicator in the navigation bar for the user. Typically this is built into the framework, so all you need to do is add some Javascript that adds the active class to whatever link represents the current page.

The active class usually does a good job of showing the user where they are, but the problem is that the active indicator is usually only color. This violates WCAG 2.0 Success Criterion 1.4.1 (Level A): “Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.” To solve this problem, sometimes an arrow can be used to indicate the current page. For example, in the default template in Ensemble, the left-side navigation has an arrow that shows the user which page they are on.

Although color alone isn’t a great indicator of showing the user which page they are on, it is important not to add other things to show the active page unless it is in Ensemble or it has been approved by UX.

Accommodate Multiple Navigation Areas with aria-label

When using a screen reader with more than one navigation bar (think secondary nav in Ensemble or a side navigation, as shown above), it is important to differentiate the two. A screen reader would label them both as “navigation”, as that is the default label for anything with the role=”navigation” or nav element. To solve this problem, WAI-ARIA has a global aria-labelledby relationship attribute to provide a label with heading text.