Other Thoughts

When our team talks to clients about website accessibility, we break it down into three categories: content, design and development. In this post, we’ll cover the key considerations from a development perspective. Check out the previous posts in our accessibility series for details on content and design. If you’re looking for an overview of website accessibility and why it matters, give this post a read.

The basics

As you commit to making your website more accessible, the most comprehensive and trusted reference is the Web Content Accessibility Guidelines (WCAG). This series of testable criteria was established by the Web Accessibility Initiative (WAI), and it sets the international accessibility standards.  A more condensed version of current standards can be found on webaim.org or weba11y has a great resource library that outlines each item in plain english.

Development details

Many elements come into play when we talk about developing for accessibility. There are a range of edits that can be done “under the hood” to ensure the website code properly interacts with screen readers and other assistive technology tools.  

WebAim.org breaks down many of the elements we test for when adhering to accessibility standards, and helpfully explains why they’re important.  A comprehensive list can be found here: https://webaim.org/standards/wcag/checklist.  Below are a few examples we’ve pulled from their list to help understand what the development process of making a site accessible entails.  This is by no means a fully exhaustive list, but it provides a view into what goes into developing for accessibility from a coding perspective.  The range of implementation details are vast and depend on project circumstances.

Alt Text

Alt text provides context for images and videos on your website with a written description of the content.  Screen readers rely on this alt text to convey meaning to visually impaired users.

  • It’s important because:
    If an image or video does not provide alternative text, a screen reader has no content to present to the user. The user will miss out on content and context within the page. 
  • We code for this by:
    Adding appropriate alternative text that describes the content of the image. You may be asked to provide this for the images you decide to include in your website. 

ARIA Labels 

ARIA labels (Accessible Rich Internet Applications) are used to supplement HTML in order to clarify the content or use of website elements for users with disabilities who use assistive technologies.  A few assistive technologies that leverage ARIA labels for information include web browser settings, text-to-speech and voice recognition.

  • It’s important because:
    ARIA labels provide context to screen readers and other assistive technologies so that users who don’t have the benefit of seeing the screen can understand the entirety of the page.
  • We code for this by:
    Adding an ‘aria-label’ element in areas necessary. For example, in a search form, the user needs to know that the form is for searching, not for entering user info. 

Navigation Options

Users with vision impairment often use their keyboard, rather than a mouse, to navigate a website. The structure of the navigation must be clear and predictable for keyboard users.

  • It’s important because:
    Some users do not have motor ability or vision ability to use a mouse. If they cannot navigate your site on a keyboard, they do not have access to the content on your site. 
    A screen reader and thus user will miss elements of the site if the screen reader cannot tab through properly. Additionally, a user will have trouble understanding content on the site if the screen reader tabs through the elements out of order. 
  • We code for this by:
    Ensuring that the order of elements on the page is accurately reflected when using a screen reader. This often requires manual testing. We also include focus states for each element, so that the screen reader can stop on each element. 

Clean Code Structure

Coding your site with logical, well organized HTML increases the likelihood that various browsers and assistive reading devices will accurately handle your content. This is also best practice for SEO and for coding in general. 

  • It’s important because:
    As a screen reader reads aloud to a user, the user relies on the screen reader to orient them within the content. The screen reader uses headings and subheadings to orient a user. If a heading level is skipped, a user may think they have missed content on the page, and may be confused. 
  • We code for this by:
    Following a logical content hierarchy of h1 > h2 > h3 and so on to break up content and organize sections and themes.  Heading levels should never be skipped. There should only be one h1 per page. 

Form Labels

Forms frequently use placeholder text in the form field to indicate to a user what data should be entered. However, a screen reader won’t be able to read this properly and users can potentially misunderstand or not know what a form field is for. A screen reader relies on properly labeled form fields. 

  • It’s important because:
    Every user needs to know what content to enter on a form – forms include not just email or sign-ups, but search fields and other content input. 
  • We code for this by:
    Including not just placeholder text for a form, but also specific form labels that are accurate and descriptive. We also make sure the label can be focused on by a screen reader, and that a mouse or keyboard can be used to focus on the form field. 

Accessible PDFs

Tagging PDF downloads on your website is an important element in making your entire site accessible. Tags for PDFs are similar to our code for headings and labels. They help establish logical reading order and make the documents searchable. Adobe offers a helpful tip sheet to show you how to do it. Tagging for PDFs is not typically in accessibility scope unless specifically agreed upon. 

Next steps

When you’re ready to consider the accessibility of your current website, there are several free tools you can use to run an audit. We’ve listed a few below to help you get started. If you need support, our team can also run the audit for you, interpret the results and create a plan of action. Want to learn more about the options? Send us a note.

 

Free Audit Tools:

Resources for deeper learning

  • https://siteimprove.com/en/resources/content-library/
  • https://webaim.org/standards/wcag/checklist