Breaking Barriers: How We Make Websites Accessible – Part 1

If you’ve been following our blog, you’d know we’ve previously highlighted the crucial role of web accessibility in creating an inclusive digital world. Not only does it expand your audience reach but also enhances usability, often leading to a more intuitive user experience.

In another post, we dived into some of the best practices and techniques for implementing the latest web accessibility guidelines – WCAG 2.2, discussing how accessible design removes barriers that could hinder functionality for users with sensory, physical, and cognitive challenges.

Today, we’re going one step further. We’re thrilled to share a detailed description of our approach to incorporating the key WCAG guidelines into our web development process.

This approach is not just about ticking boxes or meeting legal requirements; it’s about making the web a place that everyone can navigate, understand, and interact with seamlessly.

Inclusive Design,
Better Business

Enhance accessibility.
Get your website compliant now.

GO ACCESSIBLE

So, if you’re keen on learning how we make websites more accessible and user-friendly while adhering to WCAG guidelines, then you’re in the right place. 

The topic of web accessibility is very broad. So, we’ve divided our discussion into two parts, each devoted to WCAG guidelines at Levels A and AA correspondingly and our approach to putting them into practice. This is the first part of the series. 

Now, without any further ado, let’s dive in!

Web Content Accessibility Guidelines (WCAG): Three Levels of Conformance 

First, let’s take a moment to talk about the Web Content Accessibility Guidelines and their conformance levels in case they’re new to you.

WCAG serves as the roadmap to creating a more inclusive digital world. These guidelines, developed by the esteemed World Wide Web Consortium (W3C)’s Web Accessibility Initiative (WAI), outline how to make web content more accessible and user-friendly for individuals with disabilities. 

WCAG doesn’t just cover websites; it extends its reach to applications and other forms of digital content too, making it a truly universal standard.

WCAG has established three distinct levels of conformance to ensure that all web content is accessible to everyone, regardless of their ability:

1. Level A: This is the bare minimum level of conformance. It outlines the most basic web accessibility features that all sites should incorporate.
2. Level AA: This level includes all Level A requirements, plus some additional ones. Many organizations aim to meet this level as it’s seen as a good balance between accessibility and implementation effort.
3. Level AAA: This is the gold standard in web accessibility, encompassing all requirements from Levels A and AA, as well as some advanced AAA requirements.

In this and next articles, we delve deep into the intricacies of Levels A and AA. 

With that being said, here is how we approach the WCAG implementation at Level A. 

How We Implement WCAG Recommendations for Our Clients

Level A

#1: Non-Text Content

The WCAG recommendation 1.1.1 is centered around non-text content, which includes elements like images, icons, charts, and image maps. According to this guideline, all such non-text content must be accompanied by alternative text that describes its meaning or purpose.

Why is it Important?

Non-text content forms a significant part of web content today. Images, charts, and icons not only break the monotony of text but also help in better understanding and retention of information. However, for people with certain disabilities, these elements may pose challenges. This is where the importance of alternative text comes in.

The alternative text, also known as alt text, provides a textual description of non-text content. It ensures that when images or other non-text elements can’t be perceived (for example, if images don’t load or if the user is using a screen reader), the information isn’t lost.

Who Benefits the Most?

This recommendation primarily benefits individuals with visual impairments, including blindness and low vision. By providing alt text, screen readers can convey the information represented by the non-text content, thereby making the web content accessible to these users.

It’s also beneficial for people with certain cognitive disabilities who might find it easier to comprehend information through text rather than through images or charts. Additionally, users with slow internet connections or those who choose to turn off images (to save data or reduce distractions) will also find alt text useful.

Our Approach 

To ensure we adhere to the guideline, here’s what we do:

1. We make sure there are alternative solutions such as audio or one-time passwords (OTP) for CAPTCHA. This ensures that even if the visual CAPTCHA is inaccessible, users can still verify their identities through other means.
2. For complex charts and graphs, we don’t just rely on short alt text. Instead, we provide a comprehensive textual summary or description that explains these elements in detail, making the information accessible to all users.
3. When using image links, we don’t stop at just including an alt attribute. We also add a title attribute to provide additional information. This helps enhance the understanding of the link’s purpose, especially for those using screen readers.

Check out these code snippets for better understanding of these practices:

<img> with alternative text:

<img src="images/logotype.jpg" width="1600" height="532" alt="alternative text from logo image">

<svg> with aria-labelledby, <title>, and <desc>:

<svg viewBox="0 0 720 800" aria-labelledby="svg-title svg-desc" role="img">
    <title id="svg-title">Pixels, My Super-friendly Cat</title>
    <desc id="svg-desc">An illustrated gray cat with bright green blinking eyes.</desc>
    ......
</svg>

Decorative svg icon:

<p>
    <svg aria-hidden="true">
        <title>checkmark</title>
        <use xlink:href="#icon-checkmark"></use>
    </svg>
    Success! Your order went through.
</p>

Social icons:

<a href="link" aria-label="Go to facebook page">
    <svg>
        <use xlink:href="#icon-facebook"></use>
    </svg>
    Facebook
</a>

<a href="link">
    <svg>
        <use xlink:href="#icon-facebook"></use>
    </svg>
    <span class="visually-hidden">Go to facebook page</span>
</a>

#2: Audio-Only and Video-Only (Prerecorded)

This WCAG recommendation refers to the requirement of providing text descriptions for prerecorded audio-only content and either text or audio descriptions for prerecorded video-only content. 

Why Is It Important?

The recommendation ensures that users who cannot hear or see can still access and understand the content. This is crucial in a world where digital content, such as podcasts, videos, and online courses, is becoming increasingly prevalent.

Who Benefits the Most?

People with hearing impairments would benefit most from text descriptions of audio-only content. For instance, a podcast episode could have a transcript, allowing those who are deaf or hard of hearing to read what is being said.

On the other hand, users with visual impairments will benefit from audio descriptions of video-only content. An audio description provides additional narration that explains what’s happening on the screen. This can include physical actions, facial expressions, costumes, scene changes, and on-screen text.

Our Approach

We provide code that you can use to add transcripts to your audio and video content later, or we can add the transcripts ourselves if you submit them to us.

As a standard practice, we also always include descriptive text for videos that lack an audio component.

Here are some examples of our code:

A video without audio that has text transcript below it:

<html lang="en">
<video controls>
    <source src="/test-assets/rabbit-video/silent.mp4" type="video/mp4">
    </source>
    <source src="/test-assets/rabbit-video/silent.webm" type="video/webm">
    </source>
</video>
<p>
    The above video shows a giant fat rabbit climbing out of a hole in the ground.
    He stretches, yawns, and then starts walking. Then he stops to scratch his bottom.
</p>

</html>

A video without audio with a separate audio track that describes the video content:

<html lang="en">
<video controls>
    <source src="/test-assets/rabbit-video/silent.mp4" type="video/mp4" />
    <source src="/test-assets/rabbit-video/silent.webm" type="video/webm" />
</video>

<audio controls>
    <source src="/test-assets/rabbit-video/audio-description.mp3" type="audio/mpeg" />
</audio>

</html>

A video without audio:

<html lang="en">
<p>
Not being able to use your computer because your mouse doesn't work is frustrating. Many people use only the keyboard to navigate websites. Either through preference or circumstance. 
This is solved by keyboard compatibility. Keyboard compatibility is described in WCAG. See the video below to watch the same information again in video form.
</p>
<video src="/test-assets/perspective-video/perspective-video-with-captions-silent.mp4" controls></video>

</html>

#3: Captions (Prerecorded)

The WCAG recommendation 1.2.2 requires captions to be provided for the entire audio content in prerecorded synchronized media. 

Why Is It Important?

Captions are text versions of the spoken word presented within multimedia. For an effective communication experience, it’s important that the captions are synchronized, meaning they correspond directly with the audio/visual content they represent.

Who Benefits the Most?

People with hearing impairments rely on captions to understand the context and dialogue of the video content. Without captions, these users would miss out on information, entertainment, and educational opportunities that others take for granted.

Furthermore, captions aren’t just beneficial for those with hearing difficulties. They can also aid individuals who have cognitive disorders and learning disabilities by reinforcing comprehension through visual stimulus. Plus, they are useful for people who are in a noisy environment or where sound is not allowed, and for those who are learning a new language.

Our Approach

In order to adhere to this recommendation, we ensure that all videos containing audio are accompanied by captions. This allows your users to read and understand the content if they cannot listen to it.

However, there is an exception to this rule. If a video is being used as an alternative to text content, we don’t always add captions to that video.

Additionally, to cater to a diverse audience, we strive to provide captions in various languages whenever feasible. This empowers your users to choose a language they are comfortable with, enhancing their overall experience.

#4: Audio Description or Media Alternative (Prerecorded)

The WCAG 1.2.3 recommendation suggests that for prerecorded video content that is part of synchronized media (where audio and video are presented together), either a text description or an audio description must be provided. The purpose of this is to convey information about the visual content that cannot be understood from the main audio alone.

Why Is It Important?

Visual elements in videos often convey crucial information that’s not included in the main audio. Without an audio or text description, people with visual impairments could miss out on this information, leading to an incomplete understanding of the content.

Who Benefits the Most?

The users who benefit most from this recommendation are those with visual impairments. They rely on audio descriptions to understand the context and details of the visual elements of the video. Similarly, people with specific cognitive disabilities might find text descriptions easier to comprehend than complex visual scenes.

Moreover, these alternative descriptions can also be beneficial for people without disabilities. For example, someone watching a video in a noisy environment might miss some of the audio content and could benefit from text descriptions.

Our Approach

In order to adhere to this recommendation, we endeavor to supplement the content with your audio descriptions whenever feasible. This means that we provide your narrations or explanations of key visual elements in videos for those who might not be able to see them.

Alternatively, we also add text transcripts to videos provided by you. This ensures that those who cannot hear or prefer reading can still access and understand the content.

However, there are exceptions to this rule. For videos that primarily depend on sound, such as interviews or speeches, audio descriptions are not required since the main content is already accessible through the audio itself.

#5: Info and Relationships

The WCAG recommendation 1.3.1 emphasizes the importance of conveying information, structure, and relationships through presentation in a way that can be programmatically determined or provided in text form.

Why Is It Important?

Using properly marked headings helps screen reading software understand the hierarchical structure of the content.

Similarly, associating labels with form elements makes forms more accessible by providing clear instructions or descriptions of what is expected in each form field. 

Who Benefits the Most?

In essence, by ensuring that information and relationships can be programmatically determined or available in text, we can make the web more accessible to people with various types of disabilities, including visual, auditory, cognitive, and motor impairments.

This approach aligns with the broader goal of universal design, which seeks to make products and environments usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.

Our Approach

Here is what we do to implement this recommendation: 

1. Emphasis: Rather than resorting to italics and bold texts, we highlight crucial text using <em> and <strong>. For marking quotes, we use the <blockquote> tag.
2. Headings: We structure content logically using hierarchical heading markups.
3. Tables: We employ HTML table markup for tables. For straightforward tables, we provide column headers. For more complex tables, both row and column headers are included.
4. Nested Tables: If a table within a table (nested tables) is needed, we often break the content into separate individual tables.
5. Forms: We provide the programmatic association of visible labels or appropriate accessible names to all the form elements.
6. Lists: We use ordered or unordered list markups for content that logically forms a list. We avoid turning large blocks of text that should be paragraphs into lists.
7. Grouping: We organize related form elements like radio buttons or checkboxes into groups and label them at the group level. To achieve this, we use <fieldset> and legend for native form elements and ARIA for custom form controls.
8. Lastly, we strive to frequently use native semantic markup and only resort to ARIA when absolutely necessary.

Find examples of tables here and forms here.

#6: Meaningful Sequence

The WCAG recommendation 1.3.2 states that the content on a web page or screen must be presented in a meaningful sequence when accessed by different assistive technologies or user agents. 

Why is it Important?

Essentially, this means that the order in which information is presented should make logical sense and help users understand the content better. It’s not just about the visual arrangement of elements on a page, but also how these elements are read out or interpreted by assistive technologies.

Who Benefits the Most?

People with visual impairments who use screen readers will benefit greatly from this guideline. Screen readers read out content based on its coding order, not its visual presentation. If the content is not arranged in a meaningful sequence in the code, the screen reader might relay information in a confusing or incorrect order, making it difficult for the user to comprehend.

Similarly, individuals with cognitive disabilities may also find it challenging to understand content that is not logically ordered. A meaningful sequence can aid their comprehension and make the web content easier to navigate and understand.

Moreover, people with motor disabilities who use keyboard navigation instead of a mouse would find a logically sequenced website easier to navigate. If the tab order follows a meaningful sequence, it reduces the need for unnecessary keystrokes and makes the navigation process smoother.

Our Approach

In order to adhere to the guideline, we perform the following:

1. We ensure that the information displayed on the page follows a logical flow and can be easily understood by the user.
2. Our process begins with drafting the HTML structure before proceeding with the design elements, which are managed using CSS.
3. To maintain consistency and avoid confusion, we ascertain that the visual sequence on the page aligns with the DOM order.
4. We use elements like headings, lists, and paragraphs to appropriately structure and highlight the content.
5. Lastly, we guarantee that users can clearly distinguish between the navigation menus and the main content on the page. This aids in seamless navigation and enhances user experience.

#7: Sensory Characteristics

The WCAG 1.3.3 recommendation suggests that the information or instructions provided on a web page should not rely solely on sensory characteristics such as sound, size, shape, visual location, or orientation.

Why is it Important?

The recommendation acknowledges that not all users perceive information in the same way. For instance, relying solely on color to convey information may exclude those who are color-blind. Similarly, using only audio cues may not be helpful for those with hearing impairments.

Who Benefits the Most?

People with several types of disabilities will benefit from this guideline:

1. Visual impairments: Users with low vision or color blindness may struggle to perceive information based on color or size. Therefore, providing alternative ways to access this information, such as text descriptions, can be beneficial.
2. Hearing impairments: Users who are deaf or hard of hearing may not be able to perceive information conveyed through sound. Therefore, providing visual cues or written transcripts can make the content accessible to them.
3. Cognitive disabilities: Users with cognitive disabilities, such as dyslexia or ADHD, may struggle with understanding information based on complex visual layouts or auditory signals. Providing clear and straightforward instructions in text can make the content more accessible.
4. Motor disabilities: Users with motor disabilities, who may have difficulty with precise movements, may struggle to interact with small or closely spaced interactive elements. Ensuring these elements are adequately sized and spaced can improve their user experience.

Our Approach

To ensure we’re adhering to the WCAG 1.3.3 Sensory Characteristics guideline, we take the following steps:

1. Whenever we use shapes or locations as elements of our design, we make sure to include visible labels or names for the controls. This helps users who may be unable to perceive these sensory characteristics to still understand the function of each control.
2. If we decide to use a combination of color and other sensory characteristics like shape, size, location, or orientation, we implement an additional measure. We provide off-screen text that can be read by screen readers. This assists users who might not be able to distinguish colors or perceive the other sensory aspects.
3. When sound is used as an indicator or clue, we don’t rely on it alone. We supplement the audio cue with visual or textual clues that are based on color or text. This ensures that even users who have hearing impairments can receive the necessary information.

Check out this example. 

Legal-Proof
Your Website

Accessibility implementation
for compliance.

ACT NOW

#8: Use of Color

The WCAG 1.4.1 recommendation emphasizes the importance of not relying solely on color to convey information, indicate an action, prompt a response, or distinguish a visual element.

Why Is It Important?

Relying only on color to communicate information can exclude users who have color vision deficiencies, such as color blindness or low vision.

Who Benefits the Most?

Here are the types of disabilities that would benefit most from this guideline:

1. Color blindness: Users with color blindness may not be able to distinguish between certain colors. Therefore, using color alone to convey information could lead to misunderstandings or missed information. Providing additional cues, such as patterns or text labels, can help these users understand the content better.
2. Low vision: Users with low vision might have difficulty distinguishing subtle color differences or identifying colored elements against certain backgrounds. Incorporating additional cues like contrasting colors, clear labels, or patterns can enhance their user experience.
3. Age-related vision loss: Aging can cause changes in how we perceive colors. Older adults might have difficulty distinguishing between certain colors or shades. By providing cues other than color, we can improve accessibility for this demographic.
4. Blindness: Users who are blind and use screen readers will not perceive color at all. Therefore, it’s crucial that any information conveyed through color is also available in text form.

Our Approach

In order to adhere to the guideline of not using color as the only means of conveying information, we implement the following measures:

• We ensure that any information is not solely dependent on color for comprehension. This means that any text instructions or prompts are designed in such a way that they don’t refer only to color.
• For graphs and charts where color is used to convey data, we also provide textual instructions to ensure accessibility and understanding for all users.
• To differentiate texts and user interface elements, we employ multiple visual cues. These include not just color, but also common icons, making it easier for users to distinguish between different elements.

Click here for an example of how we implement this recommendation.

#9: Audio Control

The WCAG recommendation 1.4.2 advises that no audio should automatically play for more than 3 seconds when a web page first loads.

Why is it Important?

The main purpose of this guideline is to prevent any interference or distraction that could potentially disrupt the user’s interaction with the website. Uncontrolled audio can be particularly disorienting or distracting for certain users, and it might also overlap with screen reader output, making it difficult for visually impaired users to understand the content.

Who Benefits the Most?

This recommendation is especially important for people with these types of disabilities:

1. Hearing impaired: For users with hearing impairments, sudden, loud, or prolonged audio can be uncomfortable or even painful, particularly if they are using assistive listening devices.
2. Cognitive disabilities: People with attention deficit disorders or other cognitive disabilities might find it difficult to focus on the primary content of the website if there’s an audio playing continuously.
3. Visually impaired: For those who rely on screen readers to navigate websites, auto-playing audio can interfere with the audio feedback from the screen reader, making it challenging for them to understand and interact with the site.

Our Approach

To align with the guideline, we take the following steps:

• We avoid setting audio to play automatically whenever feasible.
• We strive to ensure that the duration of any audio clip is no longer than 3 seconds.
• In case the audio clip exceeds 3 seconds, we provide additional controls such as pause/stop buttons or other volume control mechanisms that are separate from the system’s overall volume control.
• If the audio does start playing automatically upon page opening, we make it a point to instantly draw the user’s attention to the pause/stop or volume control buttons.

#10: Keyboard

The WCAG 2.1.1 recommendation stipulates that all functionality of a web page should be operable through a keyboard interface. That means every action, including filling out text fields, selecting options, activating links, submitting forms etc., should be executable by keyboard alone, without the need for specific timings for individual keystrokes.

Why is it important?

Many people with disabilities use assistive technologies that rely on keyboard-only navigation. These include screen readers, voice recognition software, and specialized keyboards. Ensuring keyboard accessibility guarantees compatibility with these technologies.

Who Benefits the Most? 

The following groups are among those who benefit greatly from this guideline:

1. People with motor disabilities: Individuals with conditions that limit fine motor control, such as Parkinson’s disease or arthritis, may find using a mouse difficult or impossible. They often rely on keyboard navigation.
2. Blind and visually impaired users: These users typically use screen readers, which primarily rely on keyboard inputs. Therefore, making keyboard accessibility is vital for this group.
3. Users with Repetitive Strain Injuries (RSI): Using a mouse can exacerbate RSI symptoms. People with this condition often prefer to use keyboards to avoid pain and discomfort.

Our Approach

Here’s how we go about implementing the guideline:

• We ensure that every element on the page, be it buttons, links, or form controls, is accessible via the [tab] key.
• We also make sure that users can activate these elements – buttons, links, and form controls – using either the enter key or the spacebar.
• Our team writes clean HTML & CSS. This approach means our pages are operable by default with a keyboard and don’t need any specific adjustments.
• We also pay careful attention to focus. We ensure all active elements on the page have a visible focus, and that the order of focus is logical and intuitive.
• For custom UI elements, we provide a tabindex=0 to make them focusable.
• For custom scripted elements, we provide appropriate event handlers, ensuring they can be operated using their respective keys.
• We try to avoid access keys. If they are necessary, we take care to ensure they do not conflict with user agent and/or assistive technology shortcut keys.
• Finally, we ensure there is no time limit for any action requiring more than one key to operate a control. This approach ensures that users can navigate and interact with our site comfortably and at their own pace.

See an example from W3C WAI here. 

#11: No Keyboard Trap 

WCAG guideline 2.1.2 is a recommendation that aims to ensure that all users, particularly those with physical disabilities, can navigate through a website or digital platform without getting stuck in any part of it.

Why is it Important?

This guideline is crucial because some users, due to their disabilities, rely solely on the keyboard for navigating through a website. If a site or application does not follow this guideline and traps keyboard focus within a certain component, these users can find themselves unable to advance or retreat from that specific section. This can lead to a frustrating user experience and can effectively bar these individuals from fully accessing the content or services provided by the website.

To avoid this, developers should ensure that all parts of their site or application can be navigated using only a keyboard. If for some reason, keyboard focus needs to be trapped within a specific component (like a dialog box or menu), there should be a clearly communicated mechanism for escaping it, such as a specific shortcut command.

Who Benefits the Most? 

The “No Keyboard Trap” guideline primarily benefits individuals with physical disabilities. This includes:

1. People with motor disabilities: Some individuals cannot use a mouse due to conditions that limit fine motor control, such as Muscular Dystrophy or Cerebral Palsy. These users navigate the web using a keyboard or similar device.
2. Visually impaired users: People with severe visual impairments often use screen readers to interpret and navigate web content. Screen readers rely heavily on keyboard commands, so a keyboard trap can severely disrupt the user experience.
3. Users with RSI: For those suffering from RSI, using a mouse can exacerbate their condition. They might prefer to use keyboard navigation to avoid the precise, repetitive movements associated with mouse use.
4. Elderly Users: Age-related conditions like arthritis can make using a mouse difficult. Elderly users may find keyboard navigation more comfortable and less physically demanding.

Our Approach

To implement the “No Keyboard Trap” guideline, we follow these steps:

1. Enable tab navigation: We ensure that users can use the [tab] key to navigate to every element on the website and also move away from them.
2. Provide clear instructions: If there’s a section of the site where keyboard navigation is restricted for a specific reason, we provide clear instructions to users on how they can exit this keyboard trap.
3. Test keyboard-only operation: We verify the website’s accessibility by unplugging the mouse and ensuring that all parts of the site are operable using only the keyboard.
4. Stick to standard navigation: We try to adhere to standard keyboard navigation keys such as [tab], [shift]+[tab], and ‘arrow’ keys as much as possible.
5. Provide hints for custom keystrokes: If there are custom keystrokes that operate certain controls, we ensure that hints about these keystrokes are easily available to all users.
6. Ensure third-party widgets are accessible: We check that any third-party widgets used on the site are accessible and do not cause any keyboard operability issues.

#12: Character Key Shortcuts

Why is it Important?

The WCAG recommendation 2.1.4 helps mitigate the risks of keyboard shortcuts interfering with assistive technologies or triggering functions unintentionally.

If a website or web application uses keyboard shortcuts, such as pressing ‘P’ to print or ‘S’ to save, these shortcuts should not be implemented using only one-letter (including upper- and lower-case letters), punctuation, number or symbol characters. Instead, they should adhere to at least ONE of the following conditions:

1. Turn off: A mechanism is available to turn the shortcut off.
2. Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g., Ctrl, Alt, etc.).
3. Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Who Benefits the Most? 

This WCAG recommendation is particularly important for individuals with motor disabilities who rely on specific keyboard or voice commands to navigate the web. Without these guidelines, these users may accidentally trigger these shortcuts, leading to unexpected results and a frustrating user experience.

Moreover, people with visual impairments or cognitive disabilities who use screen readers or other assistive technologies might also benefit from these guidelines. Keyboard shortcuts can sometimes interfere with the commands used by these technologies. By providing an option to turn off these shortcuts or remap them, we can ensure that these users can navigate the web efficiently and effectively.

Our Approach

Here’s what we do to ensure compliance with the “Character Key Shortcuts” recommendation. 

1. We avoid single character key shortcuts. This helps prevent any unintentional actions by users, especially those using voice recognition software or those with motor disabilities.
2. We enable shortcut deactivation, providing a mechanism that allows users to turn shortcuts off. 
3. We use non-printable key combinations for shortcuts: To avoid interfering with assistive technology commands, we design our keyboard shortcuts using combinations of non-printable keys like [Ctrl], [Alt], and [Shift]. This approach significantly reduces the chances of accidental activation.
4. Activate shortcuts only with keyboard focus: We ensure that shortcut keys can only be triggered when the corresponding element has the user’s keyboard focus. This means that users won’t accidentally activate a shortcut unless they’re actively interacting with the associated element.

#13: Timing Adjustable

The WCAG recommendation 2.2.1 is centered around time-based functions on websites and web applications, specifically those that have session timeouts.

Why is it Important?

When a website or application includes a session timeout feature, it’s essential to provide an accessible way for users to adjust, extend, or disable this time limit. This is critical as not all users interact with web content at the same pace.

Who Benefits the Most? 

This WCAG recommendation is particularly beneficial for several groups of people with disabilities:

1. People with physical disabilities: For individuals with motor disabilities, it may take longer than average to input information or navigate a site due to the use of assistive technologies or other adaptive strategies. Without the ability to extend time limits, these users may experience session timeouts before they are able to complete their tasks.
2. People with cognitive disabilities: Individuals with cognitive disabilities, such as attention deficit disorder or dementia, may also require more time to read, comprehend, and react to content. If a session times out too quickly, they may lose their progress and become frustrated.
3. People with visual impairments: Blind or visually impaired users who rely on screen readers may also need more time to understand and interact with content. Screen readers often read content more slowly than a sighted person can read visually, so these users may also benefit from extended time limits.

Our Approach

We implement at least ONE of the following measures for each time limit set by the content:

1. Turn off.  We provide users with the ability to disable session time limits before they encounter them. 
2. Adjust. We allow users to adjust session time limits to a range that is at least ten times longer than the default setting. This flexibility acknowledges and accommodates the varying speeds at which different users interact with web content.
3. Extend. To prevent any loss of data or progress, we alert users before their session time expires. We include a simple mechanism, like pressing the spacebar, to extend the time limit by at least 20 seconds. We allow this extension to occur at least ten times to ensure sufficient time for users to complete their tasks.
4. Real-time exception. In situations where the time limit is integral to real-time events, such as auctions, we maintain the time limit as it’s a necessary component of the event and no alternative is possible.
5. Essential exception. If the time limit is crucial and extending it would compromise the activity, we preserve the time limit.
6. 20-hour exception: For activities with a time limit exceeding 20 hours, we consider this an exception to the rule due to its extensive duration.

#14: Pause, Stop, Hide

The WCAG recommendation 2.2.2 suggests that any moving, blinking, scrolling, or auto-updating content on a web page should be designed such that it can be paused, stopped, or hidden by the user. 

Why is it Important?

This is crucial because some users may require more time to process information, and moving or changing content can cause confusion or difficulty in understanding. By ensuring that all users can comfortably interact with web content at their own pace, websites become more user-friendly and accessible to a broader range of people.

Who Benefits the Most? 

1. Visual impairments: People with visual impairments, including conditions like low vision or complete blindness, often use screen readers to understand the content. Moving or auto-updating content can confuse these tools, making it difficult for users to follow along.
2. Cognitive disabilities: Individuals with cognitive disabilities, such as ADHD or dyslexia, might find it challenging to focus on moving or changing content. They may need more time to process information, so having the option to pause or stop the motion can make the content more accessible.
3. Age-related impairments: Older users may also struggle with fast-moving or changing content due to slower reaction times or diminished sight.
4. Motor disabilities: People with motor disabilities, who might have limited control over their movements, could find it hard to interact with moving content. For example, they might struggle to click on a moving button.

Our Approach

To implement the guideline, we follow these steps:

1. We strive to minimize the use of moving, blinking, or scrolling content as much as possible.
2. If we do use blinking content, we ensure it does not blink more than three (3) times per second. Anything more is considered flashing, which violates WCAG guidelines.
3. For any content that updates automatically, we provide users with a pause button. Alternatively, we give users the option to determine when they want the content to update.
4. If an entire web page consists of moving, blinking, scrolling, or auto-updating content, we don’t include pause, stop, or hide buttons as there is no static content to compare it with.
5. Lastly, animations indicating that a page or content is loading are exempt from this criterion, so they don’t necessarily have to meet this guideline.

Inclusive Design,
Better Business

Enhance accessibility.
Get your website compliant now.

GO ACCESSIBLE

#15: Flashes or Below Threshold

WCAG 2.3.1 states: “Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.”

Why is it Important?

This guideline is extremely important for a number of reasons:

1. Preventing seizures. Flashing content can trigger seizures in people with photosensitive epilepsy. By limiting the flash frequency to three times per second or less, we can significantly reduce this risk.
2. Reducing distractions. Flashing content can also be incredibly distracting, particularly for individuals with attention deficit disorders. It can make it difficult for them to concentrate on the main content of the web page.
3. Improving user experience. Even for users without specific health concerns, flashing content can often be annoying or disruptive. Adhering to this guideline can improve the overall user experience for all visitors.

Who Benefits the Most? 

The guideline benefits individuals with photosensitive disorders the most, including those with photosensitive epilepsy, migraines, and vestibular disorders. It also helps those with cognitive disabilities like ADHD by reducing potential distractions.

Our Approach

We strive to completely eliminate flashing content whenever it’s practical. If it’s unavoidable, we make it a point to regulate the frequency of the flashing content, ensuring it doesn’t flash more than three times in a second. 

We also use the Photosensitive Epilepsy Analysis Tool (PEAT) to verify whether the flashing content meets this specific criterion.

#16: Bypass blocks

The WCAG recommendation 2.4.1 emphasizes the need to provide a mechanism that allows users to bypass repeated blocks of content that are present on multiple pages of a website, such as top navigation bars or side menus.

Why is it Important?

The primary reason why this is important is that it significantly improves the browsing experience for users who rely on assistive technologies or those who navigate the web using only a keyboard. Without a bypass mechanism, these users would have to tab through every single link in the navigation each time they visit a new page, which can be extremely time-consuming and frustrating.

Who Benefits the Most? 

This recommendation is particularly beneficial for people with certain types of disabilities. For instance, individuals with mobility impairments who use a keyboard or a keyboard-like device rather than a mouse will find this feature helpful as it reduces the number of keystrokes needed to navigate.

Similarly, users with visual impairments who use screen readers will benefit because the screen reader won’t have to read out the same navigation links on each page, saving them time and effort.

In addition, people with cognitive disabilities like ADHD might find it difficult to concentrate if they have to navigate through the same blocks of content repeatedly. Hence, the ability to bypass these blocks can help in reducing distractions and maintaining focus on the main content.

Our Approach

In order to ensure accessibility and seamless navigation on your website, we implement the following measures:

1. We position a ‘skip link’ at the beginning of each page, allowing users to bypass navigation menus and access the main content directly.
2. For extensive pages, we incorporate additional skip links that guide users straight to specific sections of content, enhancing navigability.
3. We also ensure that these skip links become visible when they are selected or focused upon, making them easy to identify and use.
4. Clarity is key – so we label our skip links with intuitive text such as ‘Skip to main content’ or ‘Skip navigation’, so their purpose is immediately apparent to users.
5. In our usage of ARIA landmarks, we avoid redundancy by ensuring that we don’t use multiple landmarks of the same type.
6. If we do use ARIA landmarks, we assign unique names to them using the ‘aria-label’ attribute. This helps distinguish features like ‘Primary navigation’ from ‘Secondary navigation’, thereby improving the user experience.

By default, we add two links: “Skip to content” and “Back to top”:

HTML:

<body>
    <a class="accessibility" href="#main">Skip to content</a>
    <div id=”wrapper”>
        <header>...</header>

        <main id=”main”>...</main>
        <footer>...</footer>
    </div>
    <a class="accessibility" href="#wrapper">Back to top</a>
</body>

CSS:

.accessibility {
    position: absolute;
    left: -10000px;
    top: auto;
    width: 1px;
    height: 1px;
    overflow: hidden;
}

.accessibility:focus {
    position: static;
    width: auto;
    height: auto;
}

#17: Page Titles

The WCAG 2.4.2 guideline stipulates that each web page should have a title that accurately describes its content or purpose.

Why is it Important?

This is important for several reasons:

1. Improved navigation: Page titles appear in the browser tab and provide an immediate understanding of the page’s content. 
2. Assistive technology compatibility. Screen readers, commonly used by people with visual impairments, read out the page title first when a new page loads. A descriptive title can help these users understand the context and decide whether to continue exploring the page or not.
3. SEO benefits. From a technical perspective, accurate and descriptive page titles are beneficial for Search Engine Optimization (SEO). They help search engines understand the page content, which can lead to better search rankings.

Who Benefits the Most? 

This guideline primarily benefits people with visual and cognitive disabilities. For visually impaired individuals, particularly those who use screen readers, clear and descriptive page titles allow them to understand the page’s content without needing to visually scan it. 

For individuals with cognitive disabilities, such as attention deficit disorder or learning disabilities, a clear title helps them to focus on relevant content and reduces the cognitive load of interpreting the page.

Our Approach

To implement the guideline, we take the following steps:

1. We create a distinct title for each webpage.
2. We ensure that the title’s length falls within the 50-75 character range.
3. We set the page title as the H1 heading on the web page.
4. The title includes three elements: the name of the web page, a brief description, and the site’s name.
5. Lastly, we make sure that the title effectively communicates the purpose of the web page to the user.

#18: Focus Order

The WCAG recommendation 2.4.3 states that elements that receive focus while operating or navigating a web page must be in a sequence that makes sense and is meaningful.

Why is it Important?

Focus Order is important because it ensures that the navigation through a website is logical and intuitive. This is especially significant for people who navigate websites using keyboards or assistive technologies like screen readers, as they rely heavily on a logical focus order to understand and interact with the content.

If the focus order is not sequential or meaningful, these users may find it difficult to comprehend the structure and flow of the content. They could miss important information or become disoriented, leading to a frustrating user experience. In worst-case scenarios, they might not be able to use the site at all.

Who Benefits the Most?

People with a variety of disabilities benefit from a logical and meaningful focus order:

1. Visual impairments. People with visual impairments, including blindness, often use screen readers to navigate websites. These tools follow the focus order of the page, so a logical sequence is crucial for these users to understand the content.
2. Motor disabilities. People with motor disabilities may use keyboards or other non-mouse devices to navigate a website. A logical focus order helps them move through the elements of a web page without unnecessary back-and-forth tabbing.
3. Cognitive and neurological disabilities. For individuals with cognitive and neurological disabilities, a predictable and logical focus order can reduce confusion and make it easier to understand and interact with web content.

Our Approach 

To implement the guideline, we do the following:

• Steer clear of using tabindex values greater than one (1) when handling focus order. This is because they could override the logical tab order, leading to potential confusion.
• Strive to ensure that the focus order matches the reading order as closely as possible. This is essential for maintaining a logical and user-friendly navigation flow throughout the content. A significant deviation from this could lead to confusion, especially for users with disabilities.

#19: Link Purpose (in Context)

The WCAG recommendation 2.4.4 stipulates that the purpose or target of a link should be identifiable either from the link text alone, its associated content, or its surrounding content.

Why is it Important?

This guideline is important for several reasons:

1. Clarity and navigation. Clear link texts aid navigation by informing users about where the link leads before they click on it. This helps all users, but especially those with cognitive disabilities, as it reduces the cognitive load required to navigate the website.
2. Assistive technology users. For users who use screen readers, clear link descriptions are essential. Screen readers often allow users to browse a list of links out of context, so having a meaningful link text helps them understand the purpose of each link.
3. User Orientation: It helps users understand their location in a website or application, preventing disorientation.

Who Benefits the Most?

People with visual impairments, cognitive limitations, and attention deficit disorders stand to benefit the most from this recommendation. For instance, someone with a visual impairment using a screen reader will better understand the context and destination of a link if it’s labeled effectively. 

Similarly, someone with a cognitive disability will find it easier to navigate a website if the links accurately describe where they lead, reducing the cognitive effort required to understand and navigate the site.

Our Approach 

To implement the WCAG guideline 2.4.4, we take several steps:

1. We make sure that the link text itself clearly indicates its purpose. For example, instead of vague phrases, we use descriptive texts such as “My Blog” or “Visit our Blog“.
2. If an image is used as a link, we always provide suitable alt text to describe the link’s destination or function.
3. We avoid using ambiguous link texts like “here” or “click here”. If such phrases are necessary, we ensure they’re positioned at the end of a sentence or paragraph, where their purpose can be inferred from the surrounding context.
4. If an image and a link are placed next to each other and they both convey the same information or lead to the same destination, we avoid repeating the alt text and link text. Instead, we encapsulate the image within the link and assign an empty alt attribute (alt=””) to the image.
5. We ensure consistency by making sure that links with identical link text always lead to the same destination. This avoids confusion and enhances user experience.

Example 1:

<a data-testid="link-with-safety" href="https://www.moreycreative.com/contact"
    title="https://www.moreycreative.com/contact" data-renderer-mark="true" class="confluence-ssr-app-tgpl01">

    <u data-renderer-mark="true">Contact us today</u>

</a>

The purpose and the destination is clear to the user by just the link text alone.

Example 2:

<p>Our agency cares about our clients and each other. <a href="https://www.moreycreative.com/culture"
        title="Read the Morey Creative Culture Code"> It's key to who we are. </a>
<p>

<p> Morey Creative Studios is a Diamond Certified HubSpot Partner. <a href="/morey"
        aria-label="Read more about Morey Creative"> Read More... </a> </p>
<p> The inbound methodology is composed of three stages: attract, engage and delight. <a href="/inbound"
        aria-label="Read more about inbound marketing"> Read more... </a> </p>

Here, an aria label helps differentiate between the two instances of the “Read More” link, so it’s extra clear to the user that the link redirects to the respective articles.

#20: Pointer Gestures

WCAG guideline 2.5.1 emphasizes the importance of ensuring that all functionality on a website or application can be operated with a single pointer, without the need for multipoint or path-based gestures, unless such gestures are absolutely necessary.

Why Is It Important? 

This guideline recognizes that not all users have the ability to perform complex gestures involving multiple fingers or specific paths. By ensuring that essential functionalities can be accessed with a single pointer, individuals with motor impairments, limited dexterity, or those using alternative input devices like single-button switches can navigate and interact with the digital content effectively.

Who Benefits the Most?

The primary beneficiaries of this guideline are people with disabilities, including but not limited to:

1. Motor impairments. Individuals with motor disabilities, such as muscular dystrophy, cerebral palsy, or conditions that affect muscle control, may find it difficult or impossible to perform complex gestures. Adhering to this guideline allows them to access and engage with digital content using a single pointer, making it easier for them to navigate through websites or applications.
2. Limited dexterity. Users with limited dexterity due to conditions like arthritis, hand tremors, or injuries may struggle with precise and coordinated finger movements required for multipoint or path-based gestures. Making sure that single-pointer operation is possible enables these individuals to use the digital interface comfortably and efficiently.
3. Assistive technology users. People who rely on assistive technologies like screen readers, switch devices, or mouth-operated input devices may not have the capability to perform complex gestures. Adhering to this guideline ensures their ability to access and use the necessary functionalities using their preferred assistive technologies.
4. Older adults. Aging can bring about reduced motor skills and dexterity. By designing interfaces that don’t heavily rely on complex gestures, older adults can navigate and interact with digital content more easily, enhancing their overall user experience.

Our Approach

To meet the requirements of WCAG guideline 2.5.1, we do the following:

1. Refrain from using multi-pointer or path-based gestures as the sole method to control content.
2. Provide alternative methods, such as single tap/click or double tap/click. 
3. Our approach recognizes that one mode does not fit all, and we strive to provide inclusive experiences for individuals with diverse abilities.

#21: Pointer Cancellation

Pointer cancellation refers to a set of principles that govern the interaction between a user’s pointer (such as a mouse cursor or touchscreen tap) and the execution of a function. These principles ensure smooth and intuitive user experiences by defining how actions should be triggered and canceled.

• The first principle of pointer cancellation states that the down-event of the pointer should not initiate any part of the function. Instead, the function should be executed on the up-event of the pointer. This allows users to preview their actions before committing to them.
• The second principle is related to cancellation and undoing of functions. It states that there should be a mechanism available to abort a function before it completes or to undo the function after completion. This provides users with the flexibility to change their minds or correct any mistakes made during the execution of a function.
• The third principle, known as up reversal, ensures that the up-event of the pointer reverses any outcome of the preceding down-event. For example, if a user clicks and holds a button but then releases the pointer without completing the action, the button should return to its initial state as if it had never been clicked.
• Finally, the essential principle states that completing the function on the down-event is crucial. This means that certain functions, such as selecting text or dragging objects, rely on immediate feedback and require completion upon the initial down-event of the pointer.

Why Is It Important? 

• User satisfaction. Pointer cancellation ensures that users have control over their actions. It allows them to preview and confirm their actions before committing to them, reducing the chances of accidental or unwanted interactions. This results in a more satisfying user experience.
• Error prevention. By providing mechanisms for function cancellation and undoing, pointer cancellation helps prevent errors. Users can easily correct mistakes made during the execution of a function, minimizing frustration and potential loss of work.
• Flexibility. With pointer cancellation, users have the flexibility to change their mind or modify their actions. They can abort a function before it completes or undo it after completion, giving them a sense of control over the system.
• Efficiency. Following the essential principle of completing functions on the down-event, certain actions can be performed more efficiently. For example, selecting text or dragging objects can be done in a single gesture, saving time and effort for the user.

Who Benefits the Most? 

The Pointer Cancellation WCAG guideline primarily benefits individuals who may have tremors or mobility impairments. This guideline helps prevent accidental or erroneous pointer input, ensuring that users, regardless of their abilities, can interact with digital content more effectively and accurately.

Our Approach 

We meet the criteria set by this WCAG guideline in the following ways:

1. Ensure that a “down” event alone does not trigger any functionality.
2. Guarantee that an “up” event reverses or undoes any action triggered by a preceding “down” event.
3. Provide a mechanism that allows users to confirm the action they have performed when a “down” event executes such action.
4. Avoid the use of touchstart, keydown, and mousedown events as much as possible. These events are only used when absolutely necessary for complex functionality, such as implementing dragging and dropping. 

Legal-Proof
Your Website

Accessibility implementation
for compliance.

ACT NOW

#22: Label in Name

The WCAG recommendation 2.5.3, also known as “Label in Name,” is an important guideline for making the web more accessible to people with disabilities.

Why Is Important?

This guideline is crucial because it ensures that assistive technologies, such as screen readers, can accurately convey the purpose of an interface component. 

For instance, a button on a website might have a visual label saying “Submit.” According to this guideline, the accessible name (or ‘programmatically determined name‘) of this button should also contain the word “Submit.“

This way, when a screen reader encounters this button, it can announce “Submit” to the user, matching the visual label. If the accessible name does not match the visual label, it can lead to confusion and difficulty in interacting with the website or application.

Who Benefits the Most?

People with visual impairments, including those who are blind or have low vision, benefit significantly from this guideline. They rely heavily on screen readers and other assistive technologies to interact with digital content. By ensuring the name contains the text presented visually, we allow these users to understand and interact with the site effectively.

Additionally, this guideline can also benefit people with cognitive disabilities who use text-to-speech software. It can aid in understanding and navigating web content by providing consistent labels across visual and auditory interfaces.

Our Approach 

To implement this guideline:

1. We always ensure consistency between the accessible names such as aria-label and alt attribute, and the visible labels. They are made to match exactly, providing a seamless experience for all users.
2. We maintain a clear distinction between the visible label text and the accessible name text. They are never mixed or interspersed, ensuring clarity and ease of understanding.
3. Finally, we make sure that the accessible name begins precisely with the visible name. This practice is followed strictly, to maintain uniformity and avoid any confusion.

Example:

<img src=”sketchers.jpg”><button>Buy</button>

“Buy” isn’t informative. So, we use an aria-label like this:

<img src=”sneakers.jpg”><button aria-label=”Buy sneakers”>Buy</button>

#23: Motion Actuation

The WCAG recommendation 2.5.4 states that any functionality that can be operated by device motion or user motion should also be operable through user interface components. 

In other words, if a feature can be activated by shaking or tilting the device, there should be an alternative method to activate the same feature, such as a button or a link. This helps to prevent accidental actuation, which can often lead to frustration or confusion for the user.

Why Is It Important? 

The option to disable the response to motion is very important. Some users may have motor control issues, tremors, or other conditions that could unintentionally trigger these motion-activated functions. 

By providing the option to disable these features, the guideline ensures that these users can still interact with the content without fear of accidental activation.

Who Benefits the Most?

This guideline primarily benefits people with disabilities that affect their movement or control over their devices. This includes individuals with Parkinson’s disease, cerebral palsy, muscular dystrophy, and various other neuromuscular disorders. It also benefits older users who may have less steady hands or those with temporary conditions like a broken arm.

Our Approach 

Here is what we do to implement the Motion Actuation guideline: 

1. We offer an application setting that lets users disable ‘Shake to Undo’ and other motion-based functionalities. This empowers users with the freedom to interact with the application in a way that suits their needs and comfort levels.
2. For text input fields, we incorporate a feature where shaking the device prompts a dialog offering to undo the input. However, we also add a cancel button next to the text field, providing the same functionality without requiring any device movement. 
3. Our solutions allow users to tilt a device to navigate to the next or previous page. But understanding the diversity of users, we also integrate buttons to perform the same function, offering an alternative, more traditional means of navigation.
4. In an interactive photo viewer, users have the option to pan or move the device to change the view. To ensure all users can easily interact with this feature, we also provide controls that offer the same functionality without requiring any device movement.
5. Finally, we enabled gesture-based navigation within our solutions. However, recognizing that some users may find this challenging, we also include traditional navigation controls.

#24: Language of Page

The WCAG recommendation 3.1.1 advises that the primary language of each web page should be programmatically defined. 

Defining the primary language of a web page programmatically means that the language is specified in the code of the web page, typically within the HTML tag. 

Why Is It Important? 

This is particularly important for several reasons:

1. Screen readers. These devices read out the text on a webpage aloud. If the language is not defined, the screen reader may not use the correct pronunciation rules, leading to a confusing and difficult listening experience for users.
2. Translation tools. Web browsers and standalone tools often offer to translate webpages. If the original language is not defined, these tools may not work properly, leading to poor translations.
3. Search Engine Optimization (SEO): Search engines use the language specification to provide more accurate search results. If your website’s language is accurately defined, it’s more likely to appear in relevant searches.

Who Benefits the Most? 

• Visual impairments.  People who are blind or have low vision often use screen readers to access web content. If the language is defined, they will get the content in the correct pronunciation.
• Cognitive disabilities. People with dyslexia or other reading difficulties may use tools that change the display of text to make it easier to read. Knowing the language of the page can help these tools provide more effective support.
• Non-native speakers or multilingual users. Users who speak multiple languages or those who are not proficient in the language of the page can benefit from translation tools that use the language specification to provide accurate translations.

Our Approach 

To implement this recommendation, we take these steps:

• Ensure that each website page is equipped with a lang attribute.
• Make certain that the language code used on your website is accurate.
• Employ the correct language tokens to account for variations in language. For instance, we use lang=”en-us” for U.S. English and lang=”en-uk” for British English. This allows us to cater effectively to a diverse audience, no matter where they’re located.

<html lang="en">

For a full list of language codes, visit this page. 

#25: On Focus

The WCAG recommendation 3.2.1 states that the context of a web page should not change when a user focuses on an element.

Why Is It Important? 

This is important because unexpected changes can disorient and confuse users, especially those with cognitive disabilities like ADHD or conditions like autism. For example, if a form were to be submitted as soon as a user focused on a particular input field without giving them the chance to complete it, this could lead to frustration and difficulty in using the website effectively.

Similarly, if a submenu were to pop up unexpectedly when a user focuses on an element, it can be disorienting for people with visual impairments who use screen readers to navigate web pages. Screen readers read out the elements on a page in order, so if new elements appear unexpectedly, it can disrupt the navigation flow and make it difficult for these users to understand and interact with the page.

Who Benefits the Most? 

This WCAG recommendation primarily benefits individuals with cognitive and visual impairments.

1. Cognitive Impairments. People with cognitive disabilities such as ADHD, dyslexia, or autism can find it challenging to process unexpected changes on a web page. If the context changes when they focus on an element, it might confuse them and make navigation difficult. By ensuring a consistent and predictable behavior, this guideline aids in providing a better user experience for them.
2. Visual impairments. Individuals with visual impairments, including those who are blind or have low vision, often use assistive technologies like screen readers to navigate websites. If a new submenu pops up or a form submits automatically upon focusing on an element, it could disrupt the audio sequence of the screen reader and confuse the user. 

Our Approach

One of the measures that we implement to align with the On Focus recommendation is ensuring that no web element changes when it receives focus. This means that when a user interacts with any part of your website, they won’t encounter any unexpected or sudden alterations.

We are also careful to avoid both visual and behavioral modifications to your website. This way, we maintain a consistent, predictable user experience, which is crucial for accessibility and usability.

Our team is well-versed in creating websites using HTML & CSS, and we understand that these sites don’t have focus by default. To address this, we incorporate scripting to provide focus where necessary, ensuring every element on your site is easily accessible.

We also conduct thorough testing by unplugging the mouse and navigating the page using only the keyboard. This helps us confirm that all elements are accessible and work as expected without a mouse, further enhancing your website’s accessibility.

#26: On Input

The WCAG 3.2.2 On Input recommendation asserts that changes in any user input should not alter the context of the page unless the user is forewarned.

Why Is It Important? 

This guideline is important because unpredicted changes can be disorienting and confusing, particularly for individuals with certain disabilities. For instance, if a user selects an option from a drop-down list and the webpage automatically refreshes or navigates to a different page without prior notification, this could lead to frustration and difficulty in using the website.

Who Benefits the Most? 

People who benefit the most from this guideline are:

1. Cognitive impairments. People with cognitive disabilities such as ADHD or dementia may have difficulty processing sudden changes. Ensuring consistency in the context helps them to understand and interact with the content better.
2. Visual impairments. People with visual impairments, including those who are blind, often use screen readers to navigate websites. Sudden changes in context can disrupt the audio sequence of the screen reader, making it difficult for these users to understand what’s happening.
3. Motor impairments: People with motor impairments who use keyboards or other assistive technologies instead of a mouse might find unexpected changes disorienting and hard to navigate back from.

Our Approach 

Here’s how we implement the guideline:

• We ensure that forms on your website do not automatically submit upon data entry. This gives users ample time to review their information before confirming submission, preventing any accidental or premature submissions.
• We also pay special attention to the focus control in our forms. To maintain a predictable and user-friendly experience, we ensure that the focus does not automatically shift to the next form field once a field is filled out. This allows users to navigate the form at their own pace without any unexpected jumps.
• Every form we design includes a clearly labeled submit button. This gives users full control over when they’re ready to submit their information.
• We prioritize user control in our designs. We make sure that the process of populating data is entirely in the hands of users, thus enhancing their experience and comfort while using your site.

If there’s a change of context on your website, we always include clear instructions that are easily accessible to all user groups. This ensures that no user is left confused or disoriented, regardless of their ability or technology use.

#27: Error Identification

The WCAG recommendation 3.3.1 stipulates that when input errors can be identified automatically, items in error should be clearly marked and the error message should be described in text.

Why Is It Important? 

This guideline is crucial as it improves the user experience by providing clear, immediate feedback. When users make an error, they need to understand what went wrong and how to fix it. Providing error messages in text format ensures that all users, regardless of their abilities or the technologies they use, can understand and rectify their mistakes.

Who Benefits the Most? 

People who benefit the most from this guideline are:

1. Cognitive impairments. People with cognitive disabilities, such as dyslexia or ADHD, may have difficulty understanding complex instructions or remembering information. Clear, textual error messages can help them understand the issue and how to resolve it.
2. Visual impairments. People with visual impairments, including those who are blind, often use screen readers to navigate websites. Textual error messages can be read out by these assistive technologies, making them accessible to these users.
3. Hearing impairments: People with hearing impairments might miss audio cues indicating errors. Textual error messages provide an accessible alternative for these users.

Our Approach 

We implement the Error Identification guideline in the following ways:

• Errors on your website are always provided in text format. 
• We avoid relying solely on color or visual cues to highlight form errors. Instead, we use a combination of strategies to ensure that error identification is accessible to all users, including those with color blindness.
• We employ the “aria-describedby” attribute to programmatically link the form control with its corresponding error. 
• We never disable the submit button on forms. While some websites use this approach, we recognize it as an unfriendly practice that can frustrate and confuse users. We believe in giving users full control over their actions.
• We strive to provide clear and specific instructions when errors occur. By giving detailed explanations about the errors, we empower users to take necessary corrective action seamlessly.
• Lastly, we ensure that error messages are distinctly differentiated from regular text on the web page. This helps users easily identify and rectify the errors, enhancing their overall experience on your website.

#28: Labels or Instructions

The WCAG recommendation 3.3.2 mandates that any elements requiring user input should have clear labels. If the user input requires additional information, instructions should be provided.

Why Is It Important? 

This guideline is important because it helps users understand what is expected of them when interacting with a website. Clear labels and instructions reduce the likelihood of errors and make the user experience smoother and more enjoyable. They also help users feel more confident when navigating the site, as they know exactly what each input field requires.

Who Benefits the Most? 

The groups that benefit the most from this guideline are:

1. Cognitive impairments. People with cognitive disabilities, such as dyslexia, ADHD, or learning disabilities, can struggle with ambiguous or unclear instructions. Clear labels and instructions help these users understand what is required and how to interact with the web content.
2. Visual impairments. For users with visual impairments, including blindness, labels are crucial for understanding the purpose of each form field, especially when using screen readers or other assistive technologies.
3. Non-native language speakers: Clear labels and instructions are also beneficial for people whose first language is not the language of the website. Simplicity and clarity can make it easier for these users to understand and interact with the site.

Our Approach 

To implement the guideline, we follow these steps:

1. We ensure that every form field and control is accompanied by a clearly visible label.
2. Where form fields need specific data or a particular format, we provide detailed instructions.
3. We take great care to make sure the labels clearly identify what each field is for.
4. Using programming methods, we link the labels directly with their corresponding fields.
5. For form sections where multiple fields need to be filled out, like phone numbers or credit card details, we provide group-level labels. These labels are associated with the group of form fields. In such scenarios, we also ensure individual labels are provided through the title attribute.

Inclusive Design,
Better Business

Enhance accessibility.
Get your website compliant now.

GO ACCESSIBLE

#29: Parsing

The WCAG recommendation 4.1.1 focuses on creating web content that can be interpreted reliably by user agents, including assistive technologies.

Why Is It Important? 

The importance of this guideline cannot be overstated. Ensuring that your code doesn’t have any syntax errors means that assistive technologies, like screen readers and voice recognition software, can accurately interpret and relay your content to the user. This allows your website or application to function as intended, providing a seamless user experience for everyone.

Poorly formed or erroneous code may not pose significant issues for users without disabilities. Modern browsers are often capable of correcting or ignoring certain mistakes in code. However, people who rely on assistive technologies might encounter problems if the code isn’t correct. The assistive technology might misinterpret the code, leading to incorrect functionality or information being communicated to the user.

Who Benefits the Most? 

People with various disabilities would benefit from proper implementation of WCAG 4.1.1:

• Visually impaired individuals who use screen readers would receive accurate information, as the screen reader can correctly interpret the web content.
• People with motor impairments who use voice recognition software to navigate web content would also benefit, as the software would comprehend the web structure accurately, enabling effective navigation.
• People with cognitive disabilities could also benefit, as properly parsed websites generally have a more predictable and consistent layout.

Our Approach 

Here’s how we ensure that our solutions align with this WCAG recommendation: 

• We always use unique identifiers in our coding practices. This enables us to avoid any confusion or overlap, ensuring each element on your website is distinct and identifiable.
• We strictly adhere to the nesting rules as per specification. This means we arrange elements in a hierarchical manner, maintaining the correct parent-child relationships. This ensures the code is organized and easy to understand, promoting seamless interaction with your website.
• To prevent any redundancy or confusion, we avoid using duplicate attributes in our HTML code. This practice ensures that every attribute has a unique purpose and function, enhancing the clarity and functionality of your website.
• Lastly, we diligently ensure that every HTML element we use has both start and end tags. This practice is essential for maintaining the structure and readability of the code, which aids in the proper rendering of the website.

These practices not only make your website more accessible but also enhance its overall functionality and user experience.

#30: Name, Role, Value

WCAG recommendation 4.1.2 Name, Role, Value requires that for all user interface components, the name, role, and value are not only provided but also properly exposed to both user agents, like browsers, and assistive technologies.

Why Is It Important? 

This guideline is crucial because it enables assistive technologies to understand what an element is (name), what it does (role), and its current status (value). With this information, these technologies can accurately communicate the purpose and state of the interface component to the user, ensuring they can interact with it effectively.

Who Benefits the Most? 

The implementation of this recommendation benefits several groups of people with disabilities:

• Visually impaired individuals. These users often rely on screen readers to interpret and vocalize the content on the screen. If components are properly named and their roles and values correctly identified, screen readers can provide accurate information, enabling these users to interact with the site effectively.
• People with cognitive disabilities. Clear names, roles, and values can help make a website more understandable and predictable, which is particularly beneficial for individuals with cognitive impairments.
• Individuals with motor disabilities. Those who use alternative input devices, like voice recognition software or switch controls, also benefit from this guideline. When components have clear names, roles, and values, these devices can better interpret and interact with the content.

Our Approach 

We prioritize the following strategies to implement the WCAG 4.1.2 Name, Role, Value guideline, ensuring that your website is accessible to all users:

• We make it a point to use native HTML elements whenever possible. This practice enhances compatibility with assistive technologies, making your website more navigable and user-friendly.
• When creating custom component widgets, we apply WAI-ARIA attributes. This ensures that these components are identified correctly by assistive technologies, providing an accurate description of their purpose and function.
• We ensure that all custom widgets are operable using keyboard commands, specifically the spacebar and [Enter] keys. This allows users who rely on the keyboard for navigation to interact effectively with your website.
• We assign a tabindex value of 0 to all custom widgets. This means these elements can receive focus when users navigate through your site using the [tab] key, making your site more accessible to keyboard users.

Wrapping Up 

This concludes our round-up of the WCAG Level A key guidelines and our approach to implementing them.

In the next post, we’ll delve into the more challenging web accessibility requirements at Level AA and share our strategies to enhance the accessibility and user-friendliness of your web solutions. 

Stay tuned for more!