Web Accessibility: Making Sure Your Localization Work Is Inclusive

This is a guest post from one of ProZ.com's advertising partners, Middlebury Institute of International Studies

By: Emily Cipriani

elizabeth-woolner_laptop-braille-display_unsplash

Laptop with refreshable braille display [Photo by Elizabeth Woolner on Unsplash]

 

What is web accessibility—and how can you best incorporate it into your translation or localization content work?

Web accessibility is an inclusive practice that ensures that websites, tools, and technologies are designed and developed so that people with disabilities can use them. My recent project with Olivia Plowman, my colleague in the MA in Translation and Localization Management program at the Middlebury Institute of International Studies, investigated web accessibility from a localizer’s perspective. 

Here’s what you need to know. 

Understanding Accessibility and Assistive Technology

Examples of tools that web users with disabilities use to enhance their online experience:

  • Screen magnifiers, which make the text and/or other elements of the page larger.
  • Color changers, which can change the appearance of text, background color, and links on a page.  
  • Alternate input devices, rather than a keyboard or mouse, that track body motion or eye movement. 
  • Screen readers, which convert the contents of web pages into accessible formats such as sound narration or a braille display. 

Envato Tuts+ has a quick video overview of magnifiers and screen readers. 

 

Creating Accessible Content

To create accessible content, start with the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI), which published a public working draft of their 3.0 Accessibility Guidelines in December 2021. (They translate tons of their content for non–English speakers.) 

Visit the W3C’s tip guide for web developers, which has brief overviews of key features to include, paired with code samples.

WAI’s annotated demo website illustrates the importance of accessible design. The two sites look identical, but one version is easy for people with disabilities to navigate, and the other is nearly impossible. (The page is based on 2.0 guidelines but is still relevant today.) 

 

Accessibility Help from Content Management Systems 

Content management systems (CMSs) like WordPress and Drupal have built-in features to improve site accessibility. For WordPress, pick a theme with an “accessibility-ready” tag. You can also add a plugin like WP accessibility. For Drupal, look for the #D8AX pledge, which stands for Drupal 8 Accessibility eXperience. The MacArthur Foundation has compiled resources about WordPress, Drupal, Joomla, Squarespace, and Wix, as well as info on forms and surveys. The National Center on Disability and Access to Education has accessibility cheat sheets for Microsoft Office and Adobe.

 

Identifying Web Accessibility Issues

A number of free tools can identify potential accessibility problems in a website. My two favorites:

The WAI has a running list of all the possible web accessibility evaluation tools on the market (free and paid) globally. The list has checkers for specific locales and languages.

 

Translating Your Site: A Checklist

While localizing a game, Olivia and I wanted to be sure our computer-assisted translation (CAT) tool had the relevant text it needed from the source code. We wondered how well CAT tools pick up the non-visible text that screen readers use. 

We ran test pages through SDL Trados Studio, memoQ, and Memsource. Trados Studio did the best job picking up non-visible text, followed by memoQ, then Memsource. 

Our page evaluation checklist:

  • Alternative text for images: Describes images embedded in the web page.
  • Title attributes: Describe the site titles that may be created as images.
  • Certain CSS text for screen readers: Text does not appear to the end user. Text is only used by screen readers to help further describe the web page. 
  • Table summaries: Can help the user understand what the table shows.
  • Long descriptions: Known as “longdesc” in HTML, this provides longer descriptions to the screen reader and can be found in the website’s HTML.
  • ARIA-label attributes: Label elements of the HTML that have specific purposes, like buttons.
  • Language attribute: A label for the page’s language.
  • Sometimes applicable: Captions.

Final Thoughts on Accessibility 

This project helped me realize that accessible design is hard. Accessible design is time consuming. Done right, though, it has many benefits, including those related to translation and localization.

Automated translation is easier when web pages are accessible. When text is not embedded in images, even Google Translate’s browser extension can provide a general understanding of the content. When text is embedded in images, such tools can’t work.

I look forward to seeing more language service providers and clients pay mind to accessibility. Essential Accessibility predicts that web accessibility lawsuits will match or exceed last year’s. In our increasingly global world, understanding accessibility legal requirements isn’t just a plus; it’s a must.

Most importantly though, those who use screen readers shouldn’t ever be caught in a frustrating spiral of garbled nonsense image labels. We can play our part in making sure they won’t be. 

To learn more, see our video about the project

Topics: website localization, CAT tools, guest post, localization, accessibility, assistive technology

Subscribe to Email Updates

    Lists by Topic

    see all

    Posts by Topic

    see all

    Listen to the ProZ.com Podcast

     

    Recent Posts