#level aaa

no. 145

Make sure the meaning of abbreviations and acronyms is conveyed to assistive technologies

Defining the expanded definition of abbreviations and acronyms is beneficial to all users, but making sure the definitions are reliably conveyed back to assistive technologies is just as important to provide a truly accessible experience. When simply providing the expanded definition of what an abbreviation or acronym stands for right after the occurrence just does not feel enough, relying on ARIA to programmatically associate the meaning is the next best thing.

To do so, simply make sure that the aria-describedby property is used to programmatically associate the meaning of the abbreviation or acronym to its occurrence in content. The same approach would work perfectly if the definition of the occurrence were to appear in a footnote, or elsewhere in the same document. By programmatically binding the occurrence with its definition, assistive technologies will be able to reliably convey that information back to users, thus helping them get a better understanding of the context and content of the page. While best practice would suggest that applying this definition on the first occurrence is enough, it is up to authors to determine if they want it applied to every occurrence found within a page.

User Story

As a user using assistive technology, I want the meaning of every abbreviation or acronym used in content to be defined to my tools, so that I can more easily make sense of the content.

Simple Code Example

<p>The <span aria-describedby="def01">NATO</span> (<span id="def01">North Atlantic Treaty Organization</span>) is an intergovernmental military alliance based on the North Atlantic Treaty, which was signed on 4 April 1949.</p> Or, when used as a footnote... <p>The <span aria-describedby="def01">NATO [01]</span> is an intergovernmental military alliance based on the North Atlantic Treaty, which was signed on 4 April 1949.</p> ... <li>[01] <span id="def01">North Atlantic Treaty Organization</span></li> ...

Testing Methodology

Look for abbreviations or acronyms in the page and check that a programmatically associated explanation of what the abbreviation or acronym stands for is provided.

Specification Details

WCAG 2.0: Level AAA

Principle: Understandable

Guideline: 3.1 Readable

Success Criterion: 3.1.4 Abbreviations

Related Technique: G102

no. 144

Make sure abbreviations and acronyms are explained on their first occurrence in content

Abbreviations and acronyms are convenient when users are familiar with the jargon used on pages, but when users are not, those words can easily become confusing and prevent users from understanding important parts of the content. Fixing or avoiding this problem is easy enough; as long as authors pay attention to always defining what abbreviations and acronyms stand for when they are first used, users will easily be able pick up on their meaning. Since it is not always possible or even desirable to define abbreviations or acronyms when they are first encountered in a navigation menu, a breadcrumb or even a section heading, best practices suggest that authors define what they stand for as they are first encountered in content.

To do so, simply make sure that abbreviations and/or acronyms encountered in content are defined to users on their first occurrence, so users can understand what they mean. The method used to define abbreviations or acronyms can vary: providing a direct explanation in parenthesis right next to the occurrence, expanding the definition in a tooltip when focus is set on the occurrence, setting it up as a link to a reference in a footnote or a glossary, etc. By doing so, users will have a much better understanding of both content and context, thus helping them make sense of the information conveyed through the page.

User Story

As a user, I want to understand what every abbreviation or acronym stands for, so that I can more easily make sense of the content.

Simple Code Example

<p>The NATO (North Atlantic Treaty Organization) is an intergovernmental military alliance based on the North Atlantic Treaty, which was signed on 4 April 1949.</p>

Testing Methodology

Look for abbreviations or acronyms in the page and check that an explanation of what the abbreviation or acronym stands for is provided directly next to it. If the abbreviation or acronym is first encountered in a navigation menu or a section heading, then the explanation is provided on the first occurrence in the content of the page.

Specification Details

WCAG 2.0: Level AAA

Principle: Understandable

Guideline: 3.1 Readable

Success Criterion: 3.1.4 Abbreviations

Related Technique: G102

no. 141

Make sure users can turn images of text into real HTML text, styled with CSS

Despite an author’s best intention never to rely on images of text due to the potential issues those may create for some users, there will always be situations where the use of such images simply cannot be avoided. Maybe there isn’t enough real estate to embed a HTML text-based version of the image in the page; maybe the exact same result as the image itself cannot be achieved using HTML and CSS; maybe the designer just won’t accept anything but her carefully crafted visuals. Whatever the reason may be, when there is no way around using images of text, and authors still want to ensure users won’t run into issues while zooming in to read them, a practical option can be to provide an on-demand feature to let users turn those images of text into real HTML text, styled with CSS.

To do so, simply provide a mechanism, such as a button on the page, or a global user preference setting that will automatically replace all images of text with alternate versions, built with HTML and CSS instead. By doing so, users get to choose from different rendering options to control the visual presentation of the content, and while the majority of users would still rely on the default images of text provided, whenever users would need an option that provides more flexibility, the mechanism could come into play.

User Story

As a user who has low vision or has difficulty reading stylized text, I want every page to provide a mechanism allowing me to turn images of text into real HTML text styled with CSS, so that I can reliably control the presentation of the content in order to facilitate reading.

Simple Code Example

Not Applicable

Testing Methodology

Using the Web Developer Toolbar for Firefox, select the “Outline Images » Outline All Images” test under “Images” and check that none of the images contain informative or meaningful text. If any image contains text, validate that a mechanism is available to turn these images into HTML text, styled with CSS.

Specification Details

WCAG 2.0: Level AAA

Principle: Perceivable

Guideline: 1.4 Distinguishable

Success Criterion: 1.4.9 Images of Text (No Exception)

Related Technique: G140

no. 139

Make sure every single section of a document starts with a meaningful section heading

Longer or more complex documents are often divided into sections, such as chapters, topics, clauses, and so on. These various sections can also be broken down into subsections and subtopics. All this structure is usually conveyed visually to users through design and text indentations, but when users cannot see the page layout, the information is easily lost and making sense of the overall structure becomes difficult. To alleviate this problem, it is often necessary to provide a heading structure that defines every single section of the content.

To do so, simply make sure every single section of a document starts with a meaningful heading that either properly describes the section, or the content that follows. Whenever the structure requires it – such as in legal documents – do not hesitate to use section headings to introduce content headings as well. Providing a well-defined heading structure that clearly indicates the organization of the content facilitates navigation and also provides mental handles that aid users in understanding the content itself.

User Story

As a user using assistive technology, I want every single section in a web page to start with a meaningful heading properly describing the content that follows, so that I can reliably understand the structure of the document and easily find the information I’m looking for.

Simple Code Example

<h1>AODA - PART III</h1> <h2>3.1 ACCESSIBILITY STANDARDS</h2> <h3>3.1.1 Establishment of Standards</h3> <h4>3.1.1.1 Accessibility standards established by regulation</h4> <h3>3.1.2 Standards Development Process</h3> <h4>3.1.2.1 Process for development of standards</h4>

Testing Methodology

Using the Web Developer Toolbar for Firefox, select the “View Document Outline” test under “Information” and check that each section of the page has its own heading that properly and meaningfully identifies it.

Specification Details

WCAG 2.0: Level AAA

Principle: Operable

Guideline: 2.4 Navigable

Success Criterion: 2.4.10 Section Headings

Related Technique: G141

no. 138

Make sure users can control the pace at which automatic updates in content occur

Websites that automatically update their content can be great for a lot of users, as they have the ability to provide some of the most up-to-date information users can find on any given topic (news sites, sports results or even social media platforms instantly come to mind). But for a lot of users, including users with visual impairments or some cognitive disabilities, such websites can also mean all sorts of problems, due to content and even context unexpectedly changing as users navigate through them. While the solution to a more accessible web certainly isn’t to ban automatically updated content, allowing users some control over how and when these updates occur can make all the difference.

To do so, simply provide a mechanism that allows users to easily and intuitively control the pace at which automatically updated content is updated. This mechanism can take many forms, from an easily discoverable button at the top of the page that stops automatic updates and allows users to refresh the page at their own pace, to a setting that can be applied globally throughout a site, to control the frequency at which content is updated. Doing so will empower users who may otherwise be disturbed or unsettled by unexpected changes in content, or even context, especially when the entire page refreshes, sending the focus back at the very top of the page.

User Story

As a user using assistive technologies such as screen readers or a user with a cognitive disability making it difficult to concentrate and read content, I want the ability to postpone when content gets updated on a website, so that I can control the pace at which I consume the information and avoid being unsettled by unexpected changes in context.

Simple Code Example

Not Applicable

Testing Methodology

Looking at a page with automatically updated content, check for a mechanism or a global user preference allowing users to adjust the timing of the updates to their own pace, or alternatively, an option to completely turn off any automatic updates in content, if users so wish.

Specification Details

WCAG 2.0: Level AAA

Principle: Operable

Guideline: 2.2 Enough Time

Success Criterion: 2.2.4 Interruptions

Related Technique: G75

no. 135

Make sure audio files that contain speech information don’t have background sounds

While some best practices for accessible audio content suggest that background sounds should be at least 20 decibels lower than any foreground speech, there is always a fair probability that background sounds, whether it comes from music, people talking, etc. will create challenges for some users with hearing impairments. Any information that conflicts with the main audio track is another potential source of distraction or another potential barrier to intelligibility. In order to reliably ensure that audio files will be as accessible to users as they can be, authors should keep in mind never to have their main audio tracks compete with other sounds, or at least, provide a special version that does not.

To do so, simply make sure to avoid background sounds whenever audio files are being shared. Keep the audio file as intelligible as possible by sticking to a single, clearly defined audio track and be mindful of any noise occurring during that audio track that could negatively impact the users’ ability to clearly understand the content. If background sounds are unavoidable, then make sure they are at least 20 decibels lower than the main foreground track, or provide a second version of the audio track, clearly labelled as such, that does not have any background sounds.

User Story

As a user who is hard of hearing, I want information conveyed in audio files to be as intelligible as possible, and devoid of background sounds whenever possible, so that I can more easily understand the information conveyed.

Simple Code Example

Not Applicable

Testing Methodology

Listening to the audio file, validate that the main audio track does not compete with any background sounds, or that a second, equivalent sound file is provided, where no background noises are present.

Specification Details

WCAG 2.0: Level AAA

Principle: Perceivable

Guideline: 1.4 Distinguishable

Success Criterion: 1.4.7 Low or No Background Audio

Related Technique: G56

no. 134

Make sure foreground speech is always four times louder than background sounds

Whenever pages embed audio files, where the information being conveyed comes over some background audio (music, traffic noise, crowd murmur, yelling, etc.), end users – especially those with hearing impairments – are at a risk of having difficulty clearly discerning the information presented in the foreground. As the audio file is consumed as a single object within the page, separating the foreground audio from the background noise is usually impossible. In order to help users clearly understand the information contained in the audio file, authors need to make sure the information in the foreground comes out much louder than the information in the background when they mix their audio tracks.

To do so, simply make sure than whenever foreground information such as speech is put against background audio, that the foreground sound information is at least four times louder than the background audio. A simple rule of thumb when it comes to audio is that for every 10 decibels increment, the sound becomes twice as loud. So by making sure the foreground audio track is 20 decibels higher than the background audio, authors create sound files that will allow the foreground information to clearly stand out from the background noise. Doing so will make it much easier for people with hearing impairments to understand the information the audio file conveys.

User Story

As a user who is hard of hearing, I want information to clearly stand out when audio files also contain background noise, so that I can more easily understand the information conveyed.

Simple Code Example

Not Applicable

Testing Methodology

Using sound editing software to listen to the audio file, locate loud values of background content between foreground speech and measure that these values are always at least 20 decibels lower than the foreground speech.

Specification Details

WCAG 2.0: Level AAA

Principle: Perceivable

Guideline: 1.4 Distinguishable

Success Criterion: 1.4.7 Low or No Background Audio

Related Technique: G56

no. 133

Make sure the purpose of links can be completely determined solely from the link’s text label

While non-descriptive links such as “click here”, “more info” and “read more” are acceptable as long as they remain meaningful within their immediate context under Success Criterion 2.4.4, such links are considered inaccessible when striving for a higher level of accessibility. Indeed, under AAA level conformance, every single link needs to always provide a meaningful and descriptive text label, regardless of context. In other words, every link needs to clearly let users predict where it will lead or what its purpose is.

To do so, simply make sure that all links in a page are self descriptive and meaningful when taken out of their immediate context. Any non-descriptive link text must be modified so it becomes meaningful, or needs to be associated with a mechanism that will convey additional, contextual information, making the text label both meaningful and purposeful. This mechanism can take multiple forms, such as off-screen text using CSS, a toggle button that makes the link text or each link more meaningful, or any other method that will allow links to become meaningful to users of assistive technologies. Doing so will allow screen reader users who extract the list of links from a page to more easily navigate through content, and reliably choose the links that interest them most, while avoiding links that uninteresting to them.

User Story

As a visually impaired user using assistive technology, I want every link I encounter to be meaningful and descriptive, so that I can reliably determine what its purpose is, even when the link is taken out of its immediate context.

Simple Code Example

<a href="/training.php">Read more <span style="position: absolute; left:-10000px; top: auto; width:1px; height:1px; overflow: hidden;">about our wonderful training services</span>...</a>

Testing Methodology

Using the Accessibility Evaluation Toolbar for Firefox, select the “Links” test under “Navigation” and verify that the text label of each link contained in the page efficiently and sufficiently describes its purpose. For every non-descriptive link text, validate that the link also provides a mechanism that turns the non-descriptive link into a meaningful and descriptive link.

Specification Details

WCAG 2.0: Level AAA

Principle: Operable

Guideline: 2.4 Navigable

Success Criterion: 2.4.9 Link Purpose (Link Only)

Related Technique: F84