Web Accessibility: Top 12 Issues According to Experts

Are you concerned about web accessibility issues that might be hidden within your pages?

We recently gathered input from the Promet accessibility team concerning digital accessibility issues that are most often in need of remediation, and we came up with a Top 12 list of web accessibility mistakes and oversights. They pertain to:

1. Alt text
2. Color contrast
3. Forms
4. Headings
5. iFrames
6. Keyboard accessibility
7. Landmark roles
8. Links
9. Lists
10. Semantic markup
11. Tables
12. File attachments

 

1. Alt Text

An image might be worth a thousand words, but if someone can’t see the image, then what? What’s the status of images on your site? Make sure that they are not missing:

• The alt attribute and descriptive text,
• Enough description in the alt attribute, or
• A null alt attribute (alt="") indicating that the image is decorative and thus has no meaning.

If the image is a chart, alternative text that briefly describes it might not be enough. Complicated charts and graphs will require extra effort. The use of the longdesc attribute can be used if the narrative of your content doesn’t already include the information communicated by the image.

 

2. Color Contrast

This one can be problematic if you’re heavily invested in your branding. If a color contrast checker reveals that your branding colors don’t create sufficient contrast, there are minor fixes you can employ to achieve accessibility. The two issues we see most often are insufficient color contrast:

• Between text and background colors and 
• Between text and UI components (i.e., button) or background image(s).

This type of problem can be headed off at the pass with a well-planned design and teaching your content authors how to incorporate accessibility into the creation of their colored charts and graphs.

Read: WCAG Basics to Begin Your Accessibility Journey

 

3. Forms

Forms perform different duties. You have the search box on every page. That’s a form. That “Sign up for our Newsletter” on your homepage is a form. And let’s not forget “Contact Us.” That’s three forms and we haven’t gotten to the comment forms, e-commerce forms, or event sign up forms. So, you can see, accessible forms require considerable attention.

Now, add in the long list of issues we see to understand why your forms might be your most vulnerable objects on the page.

• Form fields found with missing labels.
• Form labels found with "for" attribute not matching another element’s ID.
• Select element’s option doesn't have value available.
• Select element doesn't have initially-selected option.
• If this selection list contains groups of related options, they should be grouped with optgroup.
• Checkboxes/Radio Buttons should be contained within a fieldset.
• Fieldsets must contain a legend element.
• Form is missing a required submit button.
• Button elements missing value and/or content.

These are fixable offenses. For example, if your button elements are missing value and/or content, this is what that means.

Inaccessible:

<input type=”submit” />

Accessible:

<input type=”submit” value=”Submit Form” />

As you can see, the fix is simple. However, the tricky part can be gaining access to the site in such a way that the solution can be applied. If you’re using a third-party plug-in or a content management system, you might not have access to the code that generates your forms.

 

4. Headings

Headings in HTML are defined via the <H1>, <H2>, <H3>, etc. elements. So often content is chunked in an article by using sub-headers styled with <strong> versus <H2>, for instance. This is not considered accessible.

When Promet Source audits website pages, we often find:

• Heading tags without content, and 
• Heading structure that is not logically nested.

What does logically nested mean? Let’s take a look.

Inaccessible:

<h1>About Us</h1>
<h4>Our History</h4>
<h6>Our Future</h6>

Accessible:

<h1>About Us</h1>
<h2>Our History</h2>
<h2>Our Future</h2>

This example makes it look like the content is the problem and it might be. However, this kind of issue can creep up in the presentation of page objects that reside outside the main content.

Read: Anatomy of a Web Accessibility Audit

 

5. iFrames

iFrames are used to display content on your web page from an external source. In this scenario, you need to think about two things: the iFrame on your page and the external content source, or third-party.

Start with ensuring your iFrame has a title, as shown in the sample code below. Then, ensure that the external content is accessible, which might not be easy if you don’t have an agreement with the source to provide accessible content. Remember, just because it came from someone else, that doesn't mean you aren't responsible.

Inaccessible:

<iframe src=”/images/maine-beach-home.png” width=”...” height=”...” />

Accessible:

<iframe title=”Maine beach home” src=”/images/maine-beach-home.png” width=”...” height=”...” />

 

6. Keyboard Accessibility

You scroll the browser window to see what’s hidden below. You place your cursor on a link or in a form field using your touchpad or mouse. Swiping and screen taps have become actions we take for granted on mobile devices. What would you do if you couldn't click or tap?

The most common keyboard accessibility issues we see are:

• Elements that are not keyboard accessible;
• Elements that are not visible when it gets focus (e.g., show a dotted border); and 
• Forms that cannot be navigated using the keyboard and other accessibility tools. (i.e. accordions).

Let’s consider the first issue. Helping a user navigate to non-link and non-form elements is often overlooked. If your page is divided into sections, allowing the user to tab through the sections can be helpful.

Inaccessible:

<div>Complementary content region</div>

Accessible:

<div tabindex=”0”>Complementary content region</div>

 

7. Landmark Roles

So far we’ve talked about aspects of web pages that you are likely aware. This next topic has to do with the W3C’s Accessible Rich Internet Applications Suite (ARIA), and the roles and attributes that you can assign to your HTML elements. 

The W3C says, “With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities.” However, it can also create issues if you apply ARIA’s roles and attributes incorrectly. For instance:

• Elements missing required landmark roles, and 
• Landmark role "presentation" is applied improperly on an element because its child elements contain semantic meaning.

Let’s consider the application of roles and semantic meaning.

Inaccessible:

<div class=”promet-logo” role=”presentation”>
    <img src=”/images/promet-logo.png” />
</div>

Accessible:

<div class=”promet-logo”>
    <img src=”/images/promet-logo.png” />
</div>

Sometimes a role assignment makes things worse, not better.

Download: Manual Accessibility Audit Template

 

8. Links

When it comes to accessible links, you have two perspectives to consider: code and content. Before we look at the coding issues for accessible hyperlinks, let’s consider content.

Links such as “Click here” and “Read more” appear often on the internet, but they’re not accessible because they lack purpose.

Imagine listening to assistive technology reading out the links on a page, “Read more. Read more. Read more.” Read more what? In order for the link to be purposeful it needs to indicate what you would be reading more about. For example: “Read More about Weather Patterns.”

Regarding coding issues, we see five coding issues on a regular basis.

• Anchor elements found with valid href attribute but no link content.
• Anchor elements found with missing href attributes.
• Broken links to 404 (page not found) pages (e.g., a link to google.co versus google.com).
• Back to top anchor link doesn't exist.
• “Skip to main content” link is missing.

The ‘skip to main content’ link accommodates success criterion 2.4.1 Bypass blocks, enabling a user of the page to bypass listening to the menu and any other blocks of content that stand in the way of them hearing the main content. Below is some code that illustrates the problem.

Inaccessible:

<body>
     <header></header>
     <main id=”main-content”></main>
</body>
     <a id=”skip-link”>Main Content</a>

Accessible:

<body>
    <a href=”main-content” id=”skip-link”>Skip to Main Content</a>
<header></header>
<main id=”main-content”></main>
</body>

 

9. Lists

If you are familiar with HTML, you might find it hard to believe that bulleted lists are, at times, not created using the <ul> and <li> elements. Just because a list visually appears as such, that doesn’t mean assistive technology will read as that way.

So, remember that:

• List elements should be marked up as a navigation list, and
• Ordered/unordered/definition lists should include list items.

What do we mean by “should include list items?” See the example below.

Inaccessible:

<ol>
     <div>Link 1</div>
     <div>Link 2</div>
     <div>Link 3</div>
</ol>

Accessible:

<ol>
     <li>Link 1</li>
     <li>Link 2</li>
     <li>Link 3</li>
</ol>

 

10. Semantic Markup

Semantic markup has to do with meaning. If something is a paragraph, use <p>, not <span> or <div>, for instance. Other examples include <form>, <table>, and <article>. These HTML elements are descriptive and carry meaning. Semantic html matters.

We often see:

• Duplicate ID attribute values found on pages, and
• Semantic markup used for emphasis or special tests (i.e. don’t use <font>).

Let’s take a look at the ID attribute that can be assigned to an HTML element. In this example, a web page has three unique forms and they each have the same ID. 

Inaccessible:

<form id=”search-header”>
<form id=”search-content”>
<form id=”search-footer”>

Accessible:

<form id=”search”>
<form id=”search”>
<form id=”search”>

The ease with which such fixes can be applied rely on how your website is created and if you have access to the code.

Read: Pros and Cons of 6 Top Web Accessibility Testing Tools

 

11. Tables

Tables are not as responsive as you will need them to be. So, if you don’t need to use a table, don’t. If you need to use a table, note that the following accessibility issues are often found.

• Table is missing caption elements.
• Table headers are missing the <th> element.
• The relationship between <td> elements and their associated <th> elements is not defined.

The last example is easy for content authors to overlook as HTML editor buttons do not insert ID and header attributes. Notice how the data cell references the table header cell that is applicable.

Inaccessible:

<table>
    <thead>
        <th>One</th>
<th>Two</th>
<th>Three</th>
</thead>
<tbody>
    <td>Column 1 content</td>
<td>Column 2 content</td>
<td>Column 3 content</td>
</tbody>
</table>

Accessible:

<table>
    <thead>
        <th id=”col1” headers=”blank” scope=”col”>One</th>
<th id=”col2” headers=”blank” scope=”col”>Two</th>
<th id=”col3” headers=”blank” scope=”col”>Three</th>
</thead>
<tbody>
    <td headers=”col1” scope=”row”>Column 1 content</td>
<td headers=”col2”>Column 2 content</td>
<td headers=”col3”>Column 3 content</td>
</tbody>
</table>

 

12. File Attachments

Accessibility is not just about the HTML page. PDFs are commonly uploaded to a page for purposes of download. They, and other files such as MS Word and Powerpoint files, are required to be accessible.

PDF accessibility requirements that we see most often pertain to the following issues:

• Untagged content,
• Missing alternative text for images, and
• Incorrect reading order.

The process to fix non-web files varies, depending on the source document.

 

Conclusion

As the above examples demonstrate, accessibility compliance calls for close attention to a wide range of details.

One of the most challenging aspects of making a site accessible tends to be of fixing the technology used to create it. If your site was created from individual HTML pages, you can edit the markup and fix many, if not all of your issues. If not, a site rebuild might be in order.

Before you build a new site, make sure that the content management system is designed to produce accessible pages and forms. It’s also essential that you audit your current pages to identify accessibility issues before they are migrated into the new site. 

Promet Source offers a path to achieving accessibility compliance for your websites, web applications and technical products. With flexible testing and remediation options, we can partner with you to ensure that you are adhering to WCAG 2.1 guidelines.  

Contact us today for a conversation on the level of training or support that best fits your needs.