Accessibility Best Practices on a Global Scale

Accessibility Best Practices on a Global Scale

You may be thinking that accessibility best practices are focus on page elements inside the body element. While this is true, there are a few other points of interest the lie elsewhere, namely the head element.

Let's review a some global page issues to watch for when testing for accessibility.

Page language

At times it can be difficult understanding the spoken word by someone from a different part of the world due to local accents or inflections. The same is true when we serve content written in a different language to that of the end user relying on voice to announce said content.

In order to ensure assistive technology is able to pronounce content in the proper accent and inflection, the HTML document content language needs to be set. This is done by adding the lang attribute to the html element, which is typically the second element in a document after the doctype declaration.

<html class="..." lang="en">
  <!-- ... -->
</html>

With the lang attribute set with the appropriate language code, content will be read aloud in the appropriate, localized accent.

Other internationalized content within content

In the case where content is written in a language other than the primary language, you can use the same pattern to output the correct accent by assistive technology.

For example, if you had a language toggle feature, one link for "English" and another for "Français," you'd need to wrap the toggle link for the language not local to the current page with the lang attribute. Or, setting the lang attribute directly onto the link would work, too.

<a href="/fr" lang="fr">Français</a>

Accessibility is also Internationalization

WCAG success criteria

This comes back to 3.1.1 Language of Page which states:

"The default human language of each Web page can be programmatically determined."

Viewport meta tag

In the past, if someone with low-vision needed to zoom their mobile or desktop browser window in order to more clearly read content, traditionally this would result in the poor experience of 2-dimensional scrolling; having to scroll horizontally as well as vertically in order to consume the content.

2D scrolling is not only an irritant for most people, it also introduces a new level of difficulty for anyone with a motor impairment or someone who relies on the keyboard alone to navigate; this requires a shift from using the Tab/Space key to read content vertically, to the arrow keys to read horizontally, and back again.

Nowadays, when someone zooms their browser to enlarge the content, the layout and styling rules defined within the CSS media queries will load as the zoom level increases. In other words, when content is zoomed the person on the other side of the screen will experience the "mobile" layout eliminating the need for horizontal scrolling, resulting in a positive user experience. This is partly due to the inclusion of the viewport meta tag:

<meta name="viewport" content="width=device-width, initial-scale=1" />

This tells the browser to set the width of the content to the width of the device itself and to scale that content to 1 on load.

If the site layout has been developed with responsive design best practices, this would be enough to remove any 2D scrolling in order for a zoom user to comfortably consume the content.

Preventing zoom

It is possible to prevent zooming the viewport using this meta tag. This is the opposite of create an accessible experience. Avoid using the following attributes:

  • maximum-scale=1.0;
  • user-scalable=no;

WCAG success criteria

This comes back to 1.3.3 Sensory Characteristics which states:

"Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions."

HTML Validator

Valid HTML is key for any solid, quality website or app. It represents the baseline experience for your users and how browsers, as well as assistive technology, will read interpret your content. This also helps to generate a consistent user experiences across devices.

Be sure to test your website or web app generated markup through the W3 Nu HTML Checker to make sure best practices are being used.

WCAG success criteria

This comes back to 4.1.1 Parsing which states:

"In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features."

Title attribute

The title attribute is a Global HTML attribute which provides "tooltip" like text when the applied element is hovered over using the mouse. It may seem like a convenient method to add extra context, but in reality, it has the potential to create a few accessibility issues:

  • The title text is only available via mouse-hover, leaving out sighted keyboard-only or voice dictation users.
  • The text which is displayed on hover may interfere with reading other near-by text for people with low-vision who require zoom software
  • Screen readers may announce the accessible name (the visible portion or text) of the element in addition to the title text, creating a redundant or overly verbose experience
  • Depending on the setup, screen readers may ignore title attribute content altogether

The general recommendation is to avoid using the title attribute completely. If you need a tooltip for specific UI consider the following:

  • Set the would-be tooltip content as plain text within parentheses
  • Adjust the UI in order to avoid requiring a tooltip
  • Create a custom, accessible tooltip

An exception

One exception to this is when it comes to providing a description for iframe elements. Screen readers need to give context to the user on what the iframe is for and one of the most straight-forward ways to accomplish this is to include a title attribute. It doesn't need to be anything fancy, just a "heads-up" to the contents of the iframe.

The reason this is a requirement is by its very nature, iframe elements represent third-party content embedded on the page. As a result, screen readers need to "step-in" to the frame before its contents can be discovered.

For example, to enter an iframe with VoiceOver, the user would first encounter the iframe via virtual cursor (Ctrl + Opt and Right arrow) then would be required to press Ctrl + Opt + Shift and Down arrow.

Resources:

Back to blog