Fifteen years after the publication of the first Web Content Accessibility Guidelines (WCAG), the lack of universal access to information on the internet remains a major stumbling block for inclusiveness and participation in today’s society. Although disabled users’ interaction with the web has experienced major improvements, a strong commitment toward social inclusion is still required from all actors involved in the web development cycle, including localization professionals.
The World Report on Disability 2011, a joint effort by the World Health Organization (WHO) and the World Bank, indicates that over a billion people in the world today experience disability, also known as functional diversity. People with special needs generally have poorer health, lower education achievements, fewer economic opportunities and higher rates of poverty than people without disabilities. This is largely due to the lack of services available to them and the multiple obstacles they have to face in their everyday lives. Since the advent of the web, these difficulties have been softened. The internet and the growth of mobile devices have helped people with mobility impairments to shop online, children with dyslexia to read adapted e-books, or blind people to regularly check their emails or independently complete administrative tasks. For all those services to be accessible across languages and communities, however, a series of requirements must be met.
Web accessibility
Web accessibility is widely defined as the practice of rendering content and services on the web accessible to all users, especially those with disabilities, so that they can perceive, understand, navigate through, interact with and contribute to them. According to the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), web accessibility depends on different components and agents working together, starting with the people involved in the web life cycle, from web professionals, particularly developers, to end users. It also depends on web software, including authoring and evaluation tools, browsers, media players and assistive technologies, as well as content — not only textual, but also aural, visual and audiovisual. Between the years 1999 and 2000, in an attempt to promote the successful interaction of all these elements, the WAI published a series of accessibility guidelines for authoring tools (ATAG), user agents (UAAG) and web content (WCAG), based on the fundamental technical specifications of the web (see Figure 1).
Version 2.0 of the Web Content Accessibility Guidelines (WCAG) was released in 2008 and has recently become an international standard (ISO/IEC 40500:2012). It also motivated international legislation, such as Section 508 in the United States, or the adoption of accessibility-oriented policy frameworks such as “i2010: A European Information Society” and the most recent “Digital Agenda for Europe.” The new WCAG 2.0 is meant to be informative and instructive, as well as to include testable statements that are not technology specific, thus solving one of the main criticisms of the previous version.
Organized around four principles — the web must be perceivable, operable, understandable and robust — WCAG 2.0 covers 12 guidelines (see Table 1) and, associated with these, 64 success criteria (expressed in three dot-separated numbers, the first four for the principle, the second for the corresponding 12 guidelines and the third for the specific success criterion), in order to determine the degree to which each guideline is met. Success is measured up to three levels: A, AA and AAA. The more As, the higher the level of accessibility, with AA as the typical threshold level for accessibility certification. For example, 2.4.1 “Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages” (level A) contributes to a more easily navigable web. 2.4.8 “Location: Information about the user’s location within a set of Web pages is available” serves the same principle, but it is considered to be level AAA. Providing a breadcrumb trail would be a sufficient technique to meet this criterion.
The diverse nature of WCAG 2.0
At first sight, these 12 guidelines may seem simple enough. However, to meet the associated success criteria, there are multiple specific techniques suggested in different supporting documents such as a quick reference; a collection of techniques and common failures, with examples, code and tests; and a guide to understanding and implementing the guidelines. These guidelines can sometimes be discouraging for web developers and designers, who often see them as impractical and too time-consuming, as explained in the book Web Accessibility: A Foundation for Research by Simon Harper and Yeliz Yesilada. This may be derived from the fact that some of the recommendations are not directly linked to the presentational and technical skills authors are used to considering when designing and developing their websites. WCAG 2.0 tends to be clear when referring to layout and technical aspects of the web, but content- and language-related components, which are also crucial in the achievement of an accessible website, are not dealt with in such a straightforward fashion.
For instance, on the one hand, we can find concrete technically-oriented guidelines, such as 2.3 “Seizures: Do not design content in a way that is known to cause seizures,” and more precisely 2.3.2 “Three Flashes: Web pages do not contain anything that flashes more than three times in any one second period.” On the other hand, content-related guidelines are usually too abstract and subject to interpretation, such as: 3.1 “Readable: Make text content readable and understandable,” or one of its associated success criteria, 3.1.3 “Unusual Words: A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon.” A specialist in the domain, a terminologist or a translator, in the case of multilingual sites, would be suitable to identify this type of content and generate an appropriate definition list or glossary.
Implementing accessibility best practices
According to the introductory pages of WCAG 2.0, these guidelines are mostly oriented to developers and designers, but also policy makers, purchasing agents, teachers and students. Over the past years, however, responsibility has been placed more and more exclusively on web developers’ shoulders.
In the case of the multilingual web, the picture is pretty much the same. Nevertheless, in a 2013 survey published in Tradumàtica and the Proceedings of the ASSETS 2013 Conference, we found that web accessibility expert evaluators with at least two years’ experience in the field believed that web accessibility should be a joint commitment by everyone involved, including content editors and localizers. More precisely, participants considered localizers to have a significantly higher level of responsibility in regard to accessibility in multilingual websites than webmasters, for instance, and nearly the same as web developers.
In “Accessibility is just another language,” an article published in MultiLingual back in April/May 2004, Ultan Ó Broin reported that understanding of the importance of accessibility within localization groups was too low. Ten years later, lack of awareness at all levels, from decision makers and project managers down to web engineers and content authors, is still recognized as one of the main reasons for low compliance with current guidelines. In this context, the localizer’s role in achieving a more inclusive web has not been officially acknowledged by the accessibility (and the localization) community as yet.
Web accessibility in the localization process
During the linguistic and cultural adaptation of web content to a specific target audience, accessibility achievements in the monolingual site could be undone, especially if web translators lack the knowledge and know-how needed. For example, not localizing textual alternatives to visual content or not correctly identifying the language of the page and its parts through the use of <alt> and <lang> attributes respectively could lead to important information loss for visually impaired people who use screen readers. Let’s assume that a couple of images are replaced in the localized French version of an originally English webpage. Appropriate text alternatives should be provided, describing the meaning or function of the new images. Similarly, we would need to declare that the page, or a particular part of it, is in French, since otherwise, assistive technologies such as screen readers would pronounce the translated content with a funny English accent, which could be hard to understand. Here, enhanced knowledge of HTML and other web technologies, web editors and the principles of CMS-based dynamic websites could come in very handy for the localizer.
Many other WCAG 2.0 requirements are relevant for localization practition-ers. For instance, 2.4.2 “Page Titled: Web pages have titles that describe topic or purpose,” or 3.1.4 “Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available.” One of the techniques available to achieve the latter is to use the <acronym> element. As a result, the meaning of the abbreviation or acronym would not only be offered to screen reader users, but also to other people not needing assistive technologies: the acronym would be underlined and, when hovering over it, the expanded form would show up (see Figure 2). From one language (or country) version to another, these acronyms may be replaced by their equivalents or omitted along with the mechanism. The example we can see in Figure 2, AIDS, has been lexicalized in Spanish and, therefore, no descriptive mechanism would be applied for the word sida.
For a website to be correctly localized, the new language versions should, at least, be as accessible as the original product. In this sense, WCAG 2.0 could be regarded as a potential added-value framework for verifying that the target product does not fail any of the accessibility requirements that the original meets.
In his 2013 book Translation and Web Localization, Miguel A. Jiménez-Crespo also embraces the idea that web accessibility is a significant component of web localization quality, although, in a way, he considers it — like usability — mainly a product of functionality (making sure the website works, in technical, cultural and pragmatic terms, for as many people as possible), but also of textual, linguistic and pragmatic aspects, ensuring intelligibility, relatedness and relevance to as many people as possible.
As noted by Maribel Tercedor in her 2010 “Translating web multimodalities: Towards inclusive web localization,” it is important to take a holistic view while implementing accessibility in the localization process, by analyzing the way that all types of existing information — verbal and nonverbal — may jointly contribute toward the intended meaning or function of the website. This would help in understanding that, depending on people’s abilities, cultural conventions and their perception and interpretation of languages (which may be more or less conditioned by functional diversity), some types of information may be experienced differently or not at all. As localizers, we can reduce the cognitive-functional load for all kinds of users by making multimodal information and action prompts cohere and feed one another.
Accessibility is not just a material feature that can be added to the digital product and then be kept or transferred automatically into the multilingual or target version. It can be an inclusion-oriented design and communication principle influenced by political, cultural, social, technical and other contextual factors. Web content or services can be made technically perceivable, operable, understandable and robust in a more straightforward, compatible form or through alternative means, but it is also crucial to comprehend the way the verbal and nonverbal information objects, the structure and the technical layer of the website interact and complement each other, first of all. Second of all, it is necessary to provide accessible meaning and potential for action — and the integration of both — to users.
As Ó Broin stated in his article, we could see localization as a form of accessibility in its own right, since it takes into consideration a specific target audience and its communicative reality and needs. Accessibility is also, in his own words, “just another language” (or “culture” we may add), meaning that the localizer must bear in mind the different material and linguistic resources that people with functional diversity have at their disposal to use and make sense of digital content and services, as well as the way that their experience of the world is conditioned by their (dis)abilities.
Localizers as contributors to web accessibility audits
As with accessibility itself, WCAG 2.0 is language dependent. In fact, the WAI considers the possibility of “Partial Conformance” in multilingual websites, where just one language version has been audited as accessible. In other words, evaluators could include a statement saying “This page does not conform, but would conform to WCAG 2.0 at level X if accessibility support existed for the following language(s)…” However, the document does not provide any further description on how to proceed in these situations. Should multilingual websites be evaluated by as many accessibility auditors as the number of language versions available? Or does the same auditor assess all language versions, but just draws conclusions about criteria conformance on his mother-tongue web version?
In our above-mentioned survey, we also aimed at exploring evaluators’ behavior when performing an accessibility assessment task on multilingual websites. Evidence suggests that no standardized assessment procedure exists yet. Nonetheless, we observed several noteworthy facts. On the one hand, the tendency among web accessibility experts is to spend no more than 25% of their time checking textual content. On the other hand, only 21% of respondents answered that they pay attention to culture-related elements that should be adapted from one version to another (such as symbols, shapes, colors, signs). Although 57% of the experts considered that monolingual and multilingual websites should not be tested for accessibility differently, those who stated the contrary indicated they would look separately at textual, multimedia and graphic content, navigation and hyperlinks, semantic structure and presentation layout because of the higher probability of these being modified across language versions and due to their language-and culture- dependent nature.
Interestingly, these elements represent the pillars of any multilingual website, where localizers’ involvement is essential, as well as the main points of intersection between localization and accessibility: presentation, structure, authoring and interaction. If they are well trained on accessibility parameters, localizers’ intervention could be of added value not only throughout the localization process, but also during accessibility evaluations. Providing the project manager, the web developer or the accessibility auditor with relevant feedback based on the localizer’s multifaceted knowledge about the target audience could contribute to a more informed assessment, and hence a multilingual web that is completely conformant with accessibility requirements.
Ideally, when a new language version is commissioned, the localization team should work closely with the original development team and assess what the expectations are in regard to accessibility, always taking into account that requirements may vary from one target culture to another, or that legislations may impose different accessibility-oriented criteria across countries. Within the same collaborative environment, an integral assessment should be carried out once the website is ready to be operational again, founded on knowledge exchange among all key actors in the web workflow, including content authors, designers, developers and webmasters. In order to visually represent this working environment, we have taken the distribution of web accessibility evaluation roles proposed by Shadi Abou-Zahra in the 2008 book Web Accessibility: A Foundation for Research, and complemented it by extending it for the multilingual web and accounting for reciprocal collaboration among actors in the web life cycle. If possible, the web accessibility expert or champion would lead the evaluation process and offer advice should further improvements be needed (see Figure 3).
If localizers lack the advanced accessibility knowledge needed to perform a fully successful job, complementary tools could be used as quality assurance technology. Currently existing accessibility checking solutions allow auditors to process a high volume of data in a short timeframe, but they also present limitations in completeness and accuracy of the evaluation performed, especially in terms of linguistic accessibility issues. However, the use of state-of-the-art controlled language software, such as Acrolinx, could help to bridge the gap between human- and machine-verifiable accessibility checkpoints. By applying accessibility-targeted controlled language rules, these tools could guide localizers on how to improve readability of the main textual body of the webpage or appropriateness of text alternatives for images (for instance, avoiding the use of redundant expressions such as image of or link to).
Increasing awareness
Taking action toward a more inclusive web is a major challenge among localization professionals and in our industry in general. Designing with internationalization in mind contributes both to accessibility and localizability, but it is not enough to achieve the broader goal of e-inclusion and access to information for all. Accessibility best practices do not only benefit people with special needs, but can also help users who are temporarily impaired — for instance, if you are in a place with a lot of noise, if you are in communities with low literacy levels or with many nonnative speakers of a given language.
Web accessibility implementation and evaluation should be a continuous process throughout the website development cycle, from the requirements phase until it is operational, irrespective of the number of language versions available in a given website. The use of evaluation, guidance and repair tools for accessibility checks can serve web professionals to have an initial snapshot of the accessibility quality of a webpage, but manual testing (human judgment) is always necessary for decision-making.
It is crucial to boost awareness within all web-related fields, as well as training on web accessibility requirements, with a view to avoiding disruptive redesign efforts. Although web accessibility has not traditionally been a recurrent topic in translation and localization curricula, over the last few years academia has been trying to introduce basic modules on the subject that have been widely welcomed by localization students. The level of knowledge acquired on accessibility matters does not need to be the same for all professionals involved in web development and maintenance. However, we should always bear in mind that only a combination of different skills and expertise can lead to an effective and successful assessment, as well as an inclusive multilingual web for all.
