Your business or website has both a fiscal and ethical case to make itself available and usable to as many people as possible, regardless of their background. Two fields concerned with increasing your application's audience are accessibility and internationalization. Too often, efforts to implement best practices in these fields fall short due to insufficient resources, synergies, or understanding. Together, we'll examine how to integrate both accessibility and internationalization into an arbitrary web application that is close to launch and into the team's practices for future sprints. Close to a launch, we need to find the most pressing issues to fix; afterwards, we'll need strategies for prioritizing continued support for an increasingly diverse user base.
Good architecture will make it feasible to spend the effort to implement internationally accessible content but the process will still be a large team effort. The application's back end must have proper separation of concerns, the front end will require an audit for good practices, and the product team will need to provide developers with the localized text for elements like tooltips, image alt tags, and form labels as well as non-text assets. Nothing in this article is a silver bullet capable of make the process of creating for users with countless needs and abilities across numerous languages and cultures easy, rather, these steps should show you that it is possible, and the increase in diverse user engagement will prove the effort worthwhile.
The gold standard for web practices is the World Wide Web Consortium (W3C) published guidelines. They provide excellent resources to help people of all roles understand and implement for accessibility and internationalization. However, like most resources on these topics, W3C does not present substantial guidance on the intersection between the topics, other than to say that the same level of accessibility should be present in localized content as is in the original content. Fortunately, scholars have stepped up to provide recommendations. Emmanuelle Gutiérrez y Restrepo and Loïc Martínez Normand in Localization and web accessibility, Jesús Torres-del-Rey and Lucía Morado Vázquez in Transferring Web Accessibility through Localization and Internationalization Standards, and Michael Cooper and Piotr Rejmer in Case study: localization of an accessibility evaluation provided the foundation of my research on the topic. This work is based on these fantastic resources, which are listed and linked at the end of the article.
Intersection of Internationalization and Accessibility
Accessibility, defined in the W3C recommendations and summarized by Gutiérrez y Restrepo and Normand, relies on four principles: information should be
- understandable, and
for all users. Perceivable means that the information should be apparent to one or more of a user's senses, it cannot be invisible. Operable means that if an application presents an interface where users can perform an action (such as clicking links, filling fields, or navigating menus), any user should be able to perform those actions. Understandable means that users should be able to grasp the meaning of content and options presented. Robust means that each of the previous principles should be maintained when the user accesses the application through a nonstandard device or with the use of assistive technology like a screen reader. More broadly, accessibility means understanding the different capabilities of your potential users and designing within those constraints.
Internationalization, per W3C, is the process of
[making] your content, application, specification, and so on, in a way that ensures it will work well for, or can be easily adapted for, users from any culture, region, or language.
Internationalization requires both a technical effort around character encodings, string length and positioning, text display, and global deployment as well as content efforts around translating both text and non-text media to target languages. Gutiérrez y Restrepo and Normand wrote that internationalizing sequences, audio, images, time-based media, and accessible media like recorded sign language is an important aspect of development that is often overlooked. Torres-del-Rey and Vázquez propose that multilingual information exchange standards are to internationalization as design standards are to accessibility, and using them in conjunction can preserve or advance progress in one field while working on the other. For more on localization alone, check out my previous article: Localization for Developers.
Both internationalization and accessibility rely on separation of concerns. In both cases, your database interactions, business logic, and other backend features can remain uniform and unchanged as long as assets, including text, are separated out for internationalization and the interface is isolated and standardized for accessibility. Then, it is possible to work at the intersection of the two fields; for example, analyzing a Spanish version of your website for navigation without a mouse. This intersection is where the real complexity lies: if you only have a general user interface for a single geographic market then there are three user groups that you're omitting.
Implementing according to just one set of standards or the other is still a worthwhile effort that will unlock an entire group of potential users. However, only the combination of standards can reach the I&A quadrant and truly fulfill the mission of making an application open to everyone. The standards writers recognize that success is a spectrum, which W3C represents with accessibility test criteria scored on an "A, AA, AAA" scale. The same scale can be applied to the transference of accessibility targets to localized versions of an application.
Once again referencing Gutiérrez y Restrepo and Normand, transferring web accessibility to new markets is as straightforward (but not simple) as fulfilling the same accessibility standards in the localized application. That said, the authors note
None of the success criteria under [Robustness] are relevant for localization purposes, as these criteria aim to ensure that the content is machine readable is a consistent way across technologies.
I disagree with this assessment. We have previously discussed character encodings and exchange standards; it is necessary to ensure that a wide range of characters are robustly supported by technology like screen readers. Furthermore, considering factors like WiFi access versus cellular data, common device manufacturers, device types, device age, and operating system and other major software preferences across a target population, either by geography or ability-based demographic, shifts the definition of "robust support" to a common set of expectations. To summarize: it doesn't matter how robust and supported your iPhone application is if the users you're trying to support run Android on tablets.
In real life, the intersection is even more complicated. What can be difficult to grapple with when working on these fields is that there is no single definition of accessibility or internationalization. An elderly user in Japan will have totally different needs than a blind user from Spain. Revisiting our chart reveals that each accessibility offering intersects every geographic market, defining a grid where each square represents the needs of a distinct group of potential users.
The first step is understanding which subfields represent the greatest numbers of your potential users. A combination of existing site metrics, user profiles, and business goals should inform the categories. Then, with your documentation and tickets or stories from completed work as a guide, construct a broad list of user actions that the application currently supports. For example, creating a new account might be prominent on that list. Imagine the process of creating an account as a user from your target group, attempt to do so on the existing application, and repeat for each target group. This fairly standard QA approach should net you a quick list of the most blocking issues that users might face. Fixing the issues according to both sets of standards will net you not only the users in the subspace of the I&A quadrant but the associated columns of users from quadrants A and I.
One critical aspect of localization is compliance with local laws. With new privacy laws enacted in California, requirements for user notification and consent can vary within the United States as well. Clicking through a cookie alert or some other notification is the first step to accessing your site. If a user can't make it past that alert with assistive technology or alternate input methods, you have effectively blocked your site to a surprisingly large number of potential users.
In general, this testing process exposes where to audit first: modals, labels, forms, and other interactive elements which, thanks to their complexity, may not be sufficiently decoupled from the rest of the application and thus may have been missed on first sweeps. These design elements can be huge roadblocks to a user perceiving, operating, and understanding your site.
With a mature application, a team didn't get so far by imagining their users as a homogeneous monolith. Rather, user personas/stories and feature requests combine to define roles that the application must support. Including accessibility and internationalization concerns into your planning, development, and testing should not require a separate team or process; rather, an expansion of existing processes and an understanding that the effort required to bake these principles into the product will consume some of the team's bandwidth. A final modification of our four quadrants reveals the subgroups within the previously uniform "Existing Support" group.
There is no need to keep these quadrants separate in your long term planning and testing. Ultimately, accessibility and internationalization needs can be accounted for in the development process just like platform specifications, screen sizes, compliance requirements, and the multitude of other constraints that your application fulfills daily.