Discover how we implement web accessibility standards, aligning with WCAG recommendations to make websites more user-friendly for individuals with disabilities.
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.
Enhance accessibility.
Get your website compliant now.
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!
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:
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.
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.
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.
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.
To ensure we adhere to the guideline, here’s what we do:
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>
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.
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.
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.
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>NOTE
If your design has no descriptive text, we add the visually-hidden class to the element that contains the descriptive text.
The WCAG recommendation 1.2.2 requires captions to be provided for the entire audio content in prerecorded synchronized media.
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.
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.
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.
NOTE
We don’t personally transcribe video or audio content. However, if you have a .vtt file, we can incorporate it into an HTML5 video. Check out this page for a comprehensive example of how this can be executed. Platforms such as YouTube offer their own editor where you can add and modify caption content directly.
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.
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.
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.
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.
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.
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.
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.
Here is what we do to implement this recommendation:
Find examples of tables here and forms here.
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.
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.
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.
In order to adhere to the guideline, we perform the following:
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.
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.
People with several types of disabilities will benefit from this guideline:
To ensure we’re adhering to the WCAG 1.3.3 Sensory Characteristics guideline, we take the following steps:
Check out this example.
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.
Relying only on color to communicate information can exclude users who have color vision deficiencies, such as color blindness or low vision.
Here are the types of disabilities that would benefit most from this guideline:
In order to adhere to the guideline of not using color as the only means of conveying information, we implement the following measures:
Click here for an example of how we implement this recommendation.
NOTE
The implementation of this requirement depends on your design significantly.
The WCAG recommendation 1.4.2 advises that no audio should automatically play for more than 3 seconds when a web page first loads.
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.
This recommendation is especially important for people with these types of disabilities:
To align with the guideline, we take the following steps:
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.
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.
The following groups are among those who benefit greatly from this guideline:
Here’s how we go about implementing the guideline:
See an example from W3C WAI here.
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.
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.
The “No Keyboard Trap” guideline primarily benefits individuals with physical disabilities. This includes:
To implement the “No Keyboard Trap” guideline, we follow these steps:
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:
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.
Here’s what we do to ensure compliance with the “Character Key Shortcuts” recommendation.
NOTE
We do not implement shortcuts on our own because it may cause conflicts with your specific shortcuts and also requires adding information to the website. We can only do it on your request.
The WCAG recommendation 2.2.1 is centered around time-based functions on websites and web applications, specifically those that have session timeouts.
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.
This WCAG recommendation is particularly beneficial for several groups of people with disabilities:
We implement at least ONE of the following measures for each time limit set by the content:
NOTE
Whether we can implement this recommendation depends on the specific details of each project.
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.
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.
To implement the guideline, we follow these steps:
NOTE
Whether we can implement this recommendation depends on the specific details of each project. It may require adding extra controls that are not included in the design and should be discussed separately.
Enhance accessibility.
Get your website compliant now.
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.”
This guideline is extremely important for a number of reasons:
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.
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.
NOTE
We avoid using our own animations that flash more than 3 times per second but can implement such animations upon your request. However, you should understand their negative impact on accessibility.
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.
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.
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.
In order to ensure accessibility and seamless navigation on your website, we implement the following measures:
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;
}
The WCAG 2.4.2 guideline stipulates that each web page should have a title that accurately describes its content or purpose.
This is important for several reasons:
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.
To implement the guideline, we take the following steps:
NOTE
By default, we use the same title for all pages. Therefore, please provide specific titles for your pages if you want us to implement this WCAG guideline.
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.
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.
People with a variety of disabilities benefit from a logical and meaningful focus order:
To implement the guideline, we do the following:
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.
This guideline is important for several reasons:
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.
To implement the WCAG guideline 2.4.4, we take several steps:
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.
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.
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.
The primary beneficiaries of this guideline are people with disabilities, including but not limited to:
To meet the requirements of WCAG guideline 2.5.1, we do the following:
NOTE
It’s more about design elements that incorporate focusable menu controls for content. For instance, carousels that lack controls and rely solely on swipe gestures, or interactive maps that only respond to touch events, do not meet this WCAG criteria.
It is essential for these elements to have visible controls, such as arrows or plus and minus buttons. In cases where the design does not include these elements, we ensure accessibility by enabling keyboard interaction. For example, a slider can switch between slides using the left and right keyboard arrows.
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 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.
We meet the criteria set by this WCAG guideline in the following ways:
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.
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.
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.
To implement this guideline:
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>
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.
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.
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.
Here is what we do to implement the Motion Actuation guideline:
NOTE
In most cases, this guideline relates to applications. A prime example would be Google Maps, which typically uses a two-finger gesture for zooming. However, for users with certain disabilities, the platform also provides plus and minus buttons to facilitate zooming in and out.
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.
This is particularly important for several reasons:
To implement this recommendation, we take these steps:
<html lang="en">For a full list of language codes, visit this page.
The WCAG recommendation 3.2.1 states that the context of a web page should not change when a user focuses on an element.
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.
This WCAG recommendation primarily benefits individuals with cognitive and visual impairments.
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.
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.
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.
People who benefit the most from this guideline are:
Here’s how we implement the guideline:
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.
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.
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.
People who benefit the most from this guideline are:
We implement the Error Identification guideline in the following ways:
NOTE
Whether this option can be applied or not depends on the design, project requirements, and installed plugins.
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.
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.
The groups that benefit the most from this guideline are:
To implement the guideline, we follow these steps:
NOTE
The visual part depends on the design, everything else can be added via aria attributes or text description with the visually-hidden CSS class.
Enhance accessibility.
Get your website compliant now.
The WCAG recommendation 4.1.1 focuses on creating web content that can be interpreted reliably by user agents, including assistive technologies.
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.
People with various disabilities would benefit from proper implementation of WCAG 4.1.1:
Here’s how we ensure that our solutions align with this WCAG recommendation:
These practices not only make your website more accessible but also enhance its overall functionality and user experience.
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.
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.
The implementation of this recommendation benefits several groups of people with disabilities:
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:
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!
This is the second post about our approach to implementing web accessibility guidelines. This time, we explain how we're working to meet the tougher WCAG Level AA requirements.
Explore the landscape of the pivotal web accessibility laws for private businesses in the developed countries and learn practical tips for compliance.
Learn why creating an e-commerce website with Drupal 8/9 and Drupal Commerce is the right decision. Looking for a suitable platform to build an online store? Among many possible choices, Drupal 8/9 coupled with the Drupal Commerce extension is one of the best options, hands down. In this post, we explain what benefits your business […]