a11yTips

Advocating social inclusion for people with disabilities and the elderly on the Web since 2000, through pragmatic universal design best practices, W3C open standards and web accessibility guidelines. Spread the word if you enjoy these tips and make sure to follow @dboudreau on Twitter to stay on top of the latest updates!

[dboudreau]

Use the aria-label property to provide additional information to users

no. 146

Make sure the purpose of links is made meaningful using the aria-label property

Providing meaningful link text that is both descriptive and conveys the proper information about the purpose of links back to users is a basic accessibility concept. Yet, many pages on the Web, even to this day, display a slew of links whose meanings can hardly be determined, even within the immediate context of their parent containers. When uninformed design decisions lean towards link text such as “Read More” or “Click Here”, the aria-label property can be used to provide additional context to the link, so it becomes more meaningful to screen reader users.

To do so, simply rely on the aria-label property to provide complementary meaning to the link, so its purpose becomes unmistakably clear to users who cannot benefit from the context provided by placement or visual design. Authors will need to keep in mind that the way assistive technology supports the aria-label property will vary. While VoiceOver announces the value of the aria-label text right after the link text, NVDA completely supplements the link text with the value of the aria-label property. Jaws, on the other hand, begins by announcing the value of the aria-label property, and then read the link text. This means that authors need to be mindful of the value provided, so the combination of link text and aria-label value remains informative.

User Story

As a visually impaired user using assistive technology, I want the purpose of links I encounter in a page to be meaningfully conveyed, so that I can reliably determine which one interests me most.

Simple Code Example

<a href="products.html" aria-label="About our products.">Read more…</a>

Testing Methodology

Using the Jim Thatcher’s Favelets for Firefox, select the “ARIA” test and look for any occurrence of aria-label displayed over a link that has ambiguous meaning, such as “Click here”, “Read more”, or the like. Check the value of the aria-label property for each such link, and determine if this value contributes enough information to help users figure out what the purpose of the link actually is.

Specification Details

WCAG 2.0: Level A

Principle: Operable

Guideline: 2.4 Navigable

Success Criterion: 2.4.4 Link Purpose (In Context)

Related Technique: ARIA8

Category: ARIA

[dboudreau]

Programmatically associate abbreviations with their definitions

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

Category: General

[dboudreau]

Define abbreviations or acronyms on their first occurrence in content

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

Category: General

[dboudreau]

Provide a second video version complete with audio description

no. 143

Make sure videos are provided in two versions, one with audio description and one without

Videos usually convey information on both the visual and audio tracks. Users who are blind and listening to dialogues may still struggle with understanding what is happening when important information taking place on the visual track (such as specific actions, characters, scene changes, on-screen text and so on) are not also conveyed on the audio track. While non-sighted users benefit from dialogues, they still need a reliable description of details happening visually, that may influence the storyline, the action or the outcome. This additional information layer can be provided through a second audio track that fills in the blanks whenever possible. Typically, this new layer is added during pauses in dialogues and sound effects, so it does not overlap with the content provided in the main audio track. Because there is only so much content that can thus be squeezed in, the amount of supplementary information that can be added to inform visually impaired users of what is going on is necessarily limited and is often insufficient.

To do so, simply provide a second version of the movie that also contains audio descriptions as part of the audio track. This can be done in a multiple of ways, such as providing another link to the second movie, or offering a media player that allow the user to choose between two versions of the same movie (one with audio descriptions and one without). Providing a second version including audio descriptions as part of the primary sound track will make this content accessible for blind people who need to hear not only the dialogue, but also the context and other aspects of the video that are not communicated by the characters' dialogue alone.

User Story

As a user who is blind, I want to have access to a version of the video that has audio descriptions, so that I will not miss any important information that is not conveyed on the visual track.

Simple Code Example

Not Applicable

Testing Methodology

Look for any media and check that a second version of the movie, complete with audio descriptions, is provided. Open this second version and listen to the movie, checking to see if gaps in dialogue are used to convey important information regarding visual content.

Specification Details

WCAG 2.0: Level A

Principle: Perceivable

Guideline: 1.2 Time-based Media

Success Criterion: 1.2.3 Audio Description or Media Alternative (Prerecorded)

Related Technique: G173

Category: General

[dboudreau]

Provide user interface components that are consistently labelled

no. 142

Make sure call to actions repeated on multiple pages are labelled consistently

Consistency and predictability are some of the most important aspects to factor in when building user interfaces that are intuitive and easy to use. Even to this day, it is not unusual to find various calls to action, such as buttons or links sharing the same functionality (print this page, order this catalog, edit this information, etc.), that are used on multiple pages, but are labelled in ways that are inconsistent from one page to another. This creates potential confusion for users, especially when these users deal with cognitive impairments of any kind, or when assistive technologies such as screen readers are involved. Calls to action that provide the same functionality and are labelled consistently contribute to helping users build confidence into the system, and their own ability to predict how to use this system efficiently.

To do so, simply make sure that user interface components that are repeated across multiple pages are consistently named using the same text labels. Doing so will help users reliably refer to these components as navigation benchmarks when going from one page to another. This is especially important when interface components are reused throughout a sequence of screens, or when users are expected to follow a certain flow. Regardless of disabilities, providing users with components that are consistently labelled when they offer the same functionality will not only provide a more predictable user experience, but will also help everyone better understand how to use the system.

User Story

As a user with or without disability, I want to rely on user interface components that are consistently labelled across pages, so that I can build trust into the system, learn how to efficiently use the site and successfully predict the purpose of each component.

Simple Code Example

Not Applicable

Testing Methodology

Looking at a sequence of pages, check that each component that shares the same function and is repeated across multiple pages is properly identified using an identical label, a name or a text alternative.

Specification Details

WCAG 2.0: Level AA

Principle: Understandable

Guideline: 3.2 Predictable

Success Criterion: 3.2.4 Consistent Identification

Related Technique: G197

Category: General

[dboudreau]

Provide a mechanism to turn images of text into real HTML text

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

Category: General

[dboudreau]

Recreate informative images using HTML and CSS instead

no. 140

Make sure none of the informative content in the page is provided in images

There is a belief, even to this day, that in order to be accessible, a page needs to avoid images altogether. While this is obviously false as long as these images are properly informed using alt text, there is still some truth to this. Images can be more difficult to perceive than regular text for some users because of the legibility of the font used, how fancy the font is, its compression ratio and how pixelated it gets when a user tries to zoom in at high level to read it properly. No matter how high of a quality an image turns out being, regular HTML text (styled with CSS) will always be more accessible when the content needs to be displayed in a different presentation. To avoid potential problems, it is preferable for informative content in pages to be provided in text, unless it is downright impossible to achieve the exact same results, using HTML and CSS.

To do so, simply make it a rule to avoid images of text whenever possible and rely on a combination of background images and superposed text, to recreate the intent of the image and achieve the expected results using CSS. With todays’ advances in browser support, there is really no reason to keep creating images of text when a similar presentation can be achieved otherwise. There are, of course, exceptions to this, such as company logos, but every image that turns out being interpreted in a similar fashion using just HTML and CSS will offer a lot more flexibility to anyone who requires modifying the default presentation of the page in order to be able to comfortably consume the content.

User Story

As a user who has low vision or has difficulty reading, I want every element of content to be provided in HTML and CSS, so that I can reliably control its presentation 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.

Specification Details

WCAG 2.0: Level AA

Principle: Perceivable

Guideline: 1.4 Distinguishable

Success Criterion: 1.4.5 Images of Text

Related Technique: G140

Category: General

[dboudreau]

Provide meaningful section headings to every section of a document

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

Category: General

[dboudreau]

Provide users with a mechanism to postpone content updates

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

Category: General

[dboudreau]

Do not rely on a single sensory characteristic to identify content

no. 137

Make sure indications in web pages are not depending on a single sensory perception

It is not unusual to come across indications on web pages that essentially depend on the user’s ability to see or hear content in order to be understood. Simple examples of this would include such indications as “select the round button below” or even “refer to the left sidebar for more information”. Whenever items within a page are referenced in the content by shape, size, sound or location, some users are bound to experience difficulties while trying to identify what these items are, or where they are located. To avoid such problems, authors should pay attention to providing indications that do not rely solely on sensory characteristics for understanding and operating content.

To do so, simply make sure that whenever indications are provided for content referenced elsewhere in a page or a web site, that these indications are not dependent on a single sensory perception, but also include the function or label of that item. For example, “select the round button below” might become “select the round button labelled GO below”. “Refer to the left sidebar for more information” might become “refer to the left sidebar under INSTRUCTIONS for more information”. Doing so will allow users who may not be able to rely on a specific sense such as sight or hearing to also identify, locate and operate a specific piece of content, as functions or labels go beyond a user’s ability to perceive information that is solely based on a single sensory characteristic.

User Story

As a user who has a disability, I want indications in content to also refer to a component’s specific function or label, so that I can identify, locate and operate any item in the page, regardless of my ability to perceive information based on a specific sensory characteristic such as sight or hearing.

Simple Code Example

Not Applicable

Testing Methodology

For any reference in the web page that mentions shape, size, or position of an object, check that the reference contains additional information that allows the item to be located and identified without any knowledge of its shape, size, or relative position.

Specification Details

WCAG 2.0: Level A

Principle: Perceivable

Guideline: 1.3 Adaptable

Success Criterion: 1.3.3 Sensory Characteristics

Related Technique: G96

Category: General

[dboudreau]

Use the title element to notify users of required fields left blank

no. 136

Make sure users are notified of required fields left blank as soon as the page reloads

There are many ways to successfully convey to assistive technologies users that required fields might have been left blank, using client-side scripting techniques or even ARIA. But when no such technique is used and the information submitted is processed directly on the server, it is important that screen reader users be quickly made aware when the form returns errors. One reliable way to do this is to notify users of a problem, as soon as the page reloads.

To do so, simply make sure that a notification of the presence of errors is indicated directly in the title element of the page. While the value of the page title should retain all relevant information about the page itself, in cases where notification error messages are required, the title element value should include such a notification, letting users know about the problem. As the page reloads, authors can dynamically modify the value of the title element, so it begins with a warning that some required fields were omitted on the previous screen. While other mechanisms must also be implemented to help track input errors returned in the page itself, providing such a notification in the page title will guarantee that the first thing screen reader users hear when reloading the page will be that the form was not successfully submitted, and that input errors or omissions need to be addressed.

User Story

As a user using assistive technology, I want to be made aware when required fields are overlooked and left blank as soon as the page reloads, so that I can enter the required data and successfully submit the form.

Simple Code Example

<title>Required fields were left blank and as a result, the form was not successfully submitted. Please fix the errors below. Contact Us – XYZ MegaCorp</title>

Testing Methodology

Fill out a form and submit it, while deliberately leaving one or more required (mandatory) fields blank. As the page reloads, validate that the page title indicates the presence of errors. Make sure that any data previously entered by the user is re-displayed, unless the data is in a security related field where it would be inappropriate to retain the data for re-display.

Specification Details

WCAG 2.0: Level A

Principle: Understandable

Guideline: 3.3 Input Assistance

Success Criterion: 3.3.3 Error Suggestion

Related Technique: G83

Category: General

[dboudreau]

Avoid background sounds when sharing audio files

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

Category: General

[dboudreau]

Mix audio so foreground speech is louder than background sounds

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

Category: General

[dboudreau]

Provide links that are meaningful from link text labels only

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

Category: Failure

[dboudreau]

Help users orient themselves in a set of pages using a breadcrumb trail

no. 132

Make sure users can rely on a breadcrumb trail to easily locate where they are

Visualizing how content has been structured on a website or application is not always easy to do, even for users who do not have disabilities. Efficiently navigating through the pages and being able to determine one’s location can be difficult, especially when the organization of the content is minimally complex or the structure is inconsistent. To help users make sense of this architecture and orient themselves efficiently throughout the site, authors should consider providing a facilitating mechanism that helps users find their way back through the sections.

To do so, simply make sure that a breadcrumb trail is provided on each page, to help users orient themselves in the information architecture of the website or application. Breadcrumb trails are usually found sitting at the top of the main region of a page, right above the main heading. While there is no mandatory area to implement them, they should always be consistently positioned at the same place in the interface. Breadcrumb trails should be implemented using links to the pages that have been accessed in the process of navigating to the current page, while leaving the last one marked up as regular text. As a best practice, consider assigning a navigation role (role=”navigation”) to the breadcrumb trail and avoid relying on HTML lists markup, as it convey misleading semantics for this type of widget.

User Story

As a user, I want to rely on a clear breadcrumb trail available on all pages, so that I can reliably locate where I am in the content and easily find my way through the content structure.

Simple Code Example

<p role=”navigation”>You are here: <a href=”/index.php”>Home</a> » <a href=”/schedule/”>Schedule</a> » <a href=”/schedule/day01/”>Day 01</a> » <a href=”/schedule/day01/tracks/”>Tracks</a> » Accessibility</p>

Testing Methodology

Navigate to a Web page and check that a breadcrumb trail is clearly displayed. Validate that the breadcrumb trail shows the correct navigational sequence to reach the current location within the structure of the site. Verify that all elements of the breadcrumb trail are implemented as links, except for the current location, which should be implemented as text.

Specification Details

WCAG 2.0: Level AAA

Principle: Operable

Guideline: 2.4 Navigable

Success Criterion: 2.4.8 Location

Related Technique: G65

Category: General

[dboudreau]

Use ARIA to expose the role of custom user interface components

no. 131

Make sure custom user interface controls’ roles are identified using ARIA roles

Authors today often use DIV and SPAN elements to create custom controls, rather than use the predefined HTML elements. For example, instead of relying on regular checkboxes, authors might design fake checkboxes using images and will use DIV elements, some CSS and a little JavaScript to turn them into what looks like checkboxes. These custom controls often look really cool, until users try to access them with anything but a mouse. When they do, they quickly realize that these cool looking checkboxes don’t quite behave like checkboxes. Sometimes, hitting the space bar won’t check them. Sometimes they won’t be part of the tabbing order. Whatever the reason may be, they’re just broken. This is because authors often forget to factor in these controls’ default behaviours. To make custom controls accessible, authors need to also expose the role of these custom user interface components.

To do so, simply make sure that whenever custom controls are created, that the proper ARIA role is added to it. WAI-ARIA provides a number of widget roles meant to convey the expected semantics to custom controls, so they truly behave like users expect them to. Some of these roles include button, checkbox, radio, listbox, option, and so on. While the use of fake controls is questionable, one cannot pretend they don’t exist, and this is when WAI-ARIA comes in. While the first rule of WAI-ARIA should always be to avoid WAI-ARIA when the equivalent feature already exists in HTML, WAI-ARIA is by far the best way to make sure the expected behaviour of custom controls is exposed to end users, regardless of the technology or tool used.

User Story

As a user using assistive technology, I want custom controls in web pages to behave like regular HTML controls do, so that I can fully control the user interface components made available in the page.

Simple Code Example

Not Applicable

Testing Methodology

For user interface components that use the role attribute, check that the value of the role attribute is one of the roles defined in the WAI-ARIA specification and that the characteristics of the user interface component match the ones described by the assigned role.

Specification Details

WCAG 2.0: Level A

Principle: Robust

Guideline: 4.1 Compatible

Success Criterion: 4.1.2 Name, Role, Value

Related Technique: ARIA4

Category: ARIA

[dboudreau]

Rely on CSS and not images of text to present section headings

no. 130

Make sure section headings are set using the CSS font-face property and not images of text

In what now may seem like the old days of web development, web designers who wanted to rely on nice, unusual or catchy fonts to display custom section headings in their pages had no choice but to use images of text, for which they defined, font face, color and size. These images of text conveyed nothing, except for the text itself and required alternative text to be considered accessible. Not only did it require a lot of work to create all those images by hand, but modifying existing images to change the text, or generating new section headings was also a productivity black hole (not to mention alt text value updates, that were often forgotten). Furthermore, users who had low vision were often faced with a situation where text content would increase, but the headings’ sizes remained unchanged. Screen reader users would receive inaccurate information from their assistive technologies. Today, with the advances in CSS and the ability to embed fonts using the font-face property, it’s become much simpler to load up and use custom fonts. This is why authors need to rely on CSS and not images of text to present section headings.

To do so, simply make sure that all section headings in the page are made of pure HTML text and are styled using CSS, instead of creating images of text. Not only will this make the maintenance of such headings much simpler for the future and nullify the need for alt text, it will allow low vision users to resize the entire content to meet their needs.

User Story

As a user with low vision, I want every text element in the page to be set using HTML and CSS instead of images, so that I can easily control the resizing of section headings in content.

Simple Code Example

@font-face {font-family: 'CustomFont'; src: url('CustomFont.woff') format('woff');} h1, h2, h3 {font-family: 'CustomFont', ‘other font choices’, sans-serif; font-size: 2em;} ... <h1>First-level Section Heading</h1>

Testing Methodology

Using the Web Developer Toolbar for Firefox, select the “Display All Images” test under “Images” and look for any section heading text that disappears.

Specification Details

WCAG 2.0: Level AA

Principle: Perceivable

Guideline: 1.4 Distinguishable

Success Criterion: 1.4.5 Images of Text

Related Technique: C22

Category: CSS