Skip to content
216digital.
Web Accessibility

Phase 1
Web Remediation for Lawsuit Settlement & Prevention


Phase 2
Real-World Accessibility


a11y.Radar
Ongoing Monitoring and Maintenance


Consultation & Training

Is Your Website Vulnerable to Frivolous Lawsuits?
Get a Free Web Accessibility Audit to Learn Where You Stand
Find Out Today!

Web Design & Development

Marketing

PPC Management
Google & Social Media Ads


Professional SEO
Increase Organic Search Strength

Interested in Marketing?
Speak to an Expert about marketing opportunities for your brand to cultivate support and growth online.
Contact Us

About

Blog

Contact Us
  • Closed Captions for Online Video Content

    With online video content becoming a cornerstone of business, marketing, and education, ensuring your videos are accessible to everyone is essential. One of the most effective ways to ensure your videos reach the widest audience possible is through closed captioning. But what exactly are closed captions? How do they work, and what actions must you take as a business or website owner? Let’s dive into everything you need to know about closed captions.

    What Are Closed Captions?

    Closed captions are text alternatives for words spoken in video or information conveyed through visual actions, designed to help people who are deaf or hard of hearing understand the content. Captions appear at the bottom of the frame and include the spoken dialogue and describe sound effects, music, or other audio cues critical to understanding the video. Closed captions can be toggled on and off by the video player, giving them control over how they experience the content.

    Who Benefits From Closed Captions?

    You might think closed captions are just for people with hearing impairments, but they benefit a much broader audience. Closed captions can help:

    • Deaf and hard-of-hearing individuals: This is the primary group that closed captions serve, allowing them to access video content on an equal footing with hearing viewers.
    • Non-native language speakers: Captions help people learning English or other languages follow along with the dialogue.
    • People in noisy environments: Imagine watching a video in a busy coffee shop or on public transportation—captions make it possible to follow along even if you can’t hear the audio.
    • People in quiet environments: Maybe you’re watching a video while a baby sleeps in the next room. With captions, you can follow the content without turning up the volume.

    Closed Captions vs. Subtitles: What’s the Difference?

    Though often used interchangeably, closed captions and subtitles aren’t quite the same. Subtitles are a text representation of the spoken words in a video. They benefit individuals with hearing impairments or people who can’t understand the spoken language but can otherwise visually perceive the content. For instance, subtitles often appear in foreign films. They don’t include sound effects or non-dialogue audio, which makes them less accessible for people who are deaf or hard of hearing.

    On the other hand, closed captions include not just the dialogue but also sound effects and other crucial audio information, making them more comprehensive.

    What are the Differences Between “Closed Captions” and “Open Captions”?

    You’ve likely heard about “closed captions” and “open captions.” The critical difference between the two is control. Closed captions can be toggled on or off by the viewer, while open captions are always on—they’re embedded into the video file and cannot be turned off. While open captions may seem convenient, they don’t provide viewers the choice to disable them, which can sometimes detract from the viewing experience for those who don’t need them.

    What Are the Legal Obligations for Closed Captioning?

    As a website owner, business owner, or content creator, you must understand your legal obligations regarding closed captions. In the U.S., several laws and regulations address digital accessibility, including captioning for video content.

    The ADA’s Requirements for Closed Captions

    The Americans with Disabilities Act (ADA) states that businesses and organizations make their services accessible to people with disabilities. While the ADA doesn’t specifically mention closed captions, it requires that public-facing businesses and websites provide equal access to their services, which can include providing captions for video content.

    The Department of Justice has provided guidance that websites should be accessible to everyone, and providing captions for videos is an integral part of ensuring your content meets the Web Content Accessibility Guidelines (WCAG), which help businesses comply with the ADA.

    FCC Requirements for Closed Captions

    For online video content that has aired on TV in the U.S., the Federal Communications Commission (FCC) requires closed captions. This regulation was expanded in 2012 with the introduction of the Twenty-First Century Communications and Video Accessibility Act (CVAA), which requires that any video programming aired on television with captions must include captions when distributed online.

    This act means that if your business uses TV ads or commercials and also posts them online, they must be captioned. Even if your content hasn’t aired on TV, following FCC rules for captioning is a good best practice.

    What Are the Benefits of Using Closed Captioning?

    Adding closed captions to your videos isn’t just about legal compliance—it can offer significant benefits to your business:

    • Expanded audience: Captioning your videos makes them accessible to more people, including those with hearing impairments, non-native speakers, and people in noisy or quiet environments.
    • Improved SEO: Search engines can’t watch videos but can read captions. By adding captions, you give search engines more context to the relevance of your content, which can improve your rankings in search results.
    • Better engagement: Captions can help viewers stay engaged with your content. Studies have shown that videos with captions have higher engagement compared to those without.
    • Increased social media reach: Many social media platforms autoplay videos without sound. Captions can ensure your message gets across, even if the audio isn’t playing.

    Best Practices for Closed Captioning

    Here are some best practices for closed captioning video content:

    • Ensure the captions are accurate: Inaccurate captions can confuse viewers or misrepresent your content. Invest in high-quality captioning services or use tools that offer high accuracy.
    • Include non-dialogue audio: Remember that closed captions provide a complete audio experience for viewers who can’t hear. Include descriptions of music, sound effects, and other audio cues that are important to understanding the content.
    • Use appropriate timing: Ensure that captions appear on-screen at the same time as dialogue or actions.
    • Keep the text readable: Ensure the text is easy to read by using a legible font, high contrast between the text and background, and large enough size to be legible.

    How to Add Captions to Videos

    There are several ways to add captions to your videos, depending on the platform and your budget:

    1. Automated captioning tools: Platforms like YouTube and Facebook offer automatic captioning, though these tools often require manual review to ensure accuracy.
    2. Manual captioning: You can create captions manually if you have the resources. Many video editing tools allow you to add captions by entering the text.
    3. Professional captioning services: You should invest in a professional service specializing in closed captioning for high-quality, accurate captions. These services usually charge based on the length of the video.

    What If My Video Service Doesn’t Support Closed Captions?

    If your platform doesn’t support closed captions, consider switching to one that does. Most popular video hosting services, including YouTube, Vimeo, and Wistia, provide captioning options. If switching platforms isn’t feasible, you can include a transcript of the video as an alternative. However, this is not a perfect substitute for closed captions, as transcripts don’t provide the real-time viewing experience that captions do.

    Conclusion

    Closed captions are a great way to make online video content accessible to everyone, and they offer many benefits, from legal compliance to better engagement and SEO. As a business or website owner, adding captions to your videos can broaden your audience, improve your content’s reach, and ensure you’re providing a digital experience that’s inclusive to everyone.

    Remember to follow the ADA, FCC, and WCAG guidelines, and always aim for accuracy and readability when adding captions to your videos. If you’re unsure if your video content is leaving you vulnerable to expensive litigation or causing you to miss out on revenue, reach out to 216digital for a courtesy evaluation.

    Bobby

    September 24, 2024
    How-to Guides, Legal Compliance, The Benefits of Web Accessibility
    ADA Compliance, Closed caption, digital accessibility, How-to, WCAG, Web Accessibility, web development
  • How to Build Accessible Slideshows and Carousels

    Slideshows and carousels can add style and organization to a website, but they often pose accessibility challenges. If not designed with care, they can be difficult for people with disabilities—especially those who use screen readers or rely on keyboard navigation—to interact with. The good news is that by following a few key practices, you can make sure your slideshows and carousels are accessible for everyone, enhancing user experience and making your site more inclusive. Let’s break it down step by step.

    Why Accessibility Matters for Slideshows and Carousels

    Before we dive into the “how,” let’s talk about the “why.” Making sure your slideshows are accessible isn’t just the right thing to do; it’s essential. Accessibility is about making sure everyone can use your website, and it helps you comply with important standards like the Web Content Accessibility Guidelines (WCAG).

    If you skip over accessibility, you could end up frustrating visitors, losing potential customers, or even dealing with legal trouble. Plus, accessible content doesn’t just help those with disabilities—it actually improves the experience for all users and makes your site more welcoming.

    Key Considerations for Accessible Slideshows

    So, how do you make your slideshows and carousels accessible? Here are a few key things to keep in mind:

    Keyboard Navigation

    Not everyone uses a mouse to navigate a website—some people rely entirely on their keyboard. This means your slideshow should be easy to move through using just the keyboard without users getting stuck or confused.

    Best Practices:

    • Tab Key Navigation (WCAG SC 2.1.1): Make sure users can use the Tab key to move forward through the slides and Shift + Tab to move backward.
    • Arrow Key Control (WCAG SC 2.1.2): Allow users to switch slides with the left and right arrow keys so they can navigate without getting lost.
    • Visible Focus(WCAG SC 2.4.7): Ensure that buttons and interactive elements like arrows have visible focus indicators so keyboard users can easily see what they’re interacting with.

    Descriptive Labels and Alt Text

    For people using screen readers, descriptive labels and alt text are super important. Without them, the screen reader can’t tell the user what a button or slide is for.

    Best Practices:

    • Alt Text for Images (WCAG SC 1.1.1): Every image in your slideshow should have alt text that describes what’s in the image. For example, if one slide shows a chart about “Website Accessibility,” the alt text should explain the key points of the chart.
    • ARIA Labels: Use an aria-label attribute to give a text label to an object, such as a “Next” and “Previous” buttons. When a screen reader encounters an object, the aria-label text is read aloud to inform the user about what it is. So, instead of a generic label like “Button,” make it something like “Next slide: About Us” so users know exactly where they’re headed.

    Pause/Play Buttons

    Automatic slideshows that move on their own can be frustrating—especially for people with cognitive or motor disabilities. Always give users control over the slideshow with pause and play options.

    Best Practices:

    • Pause/Play Button (WCAG SC 2.2.2): Make sure there’s a clearly labeled button to pause or play the slideshow and that it’s easy to use with both the mouse and keyboard.
    • Adjustable Timing (WCAG SC 2.2.1): For each slide transition, users should be able to turn off, adjust, or extend the time before the slide changes. This ensures that users have enough time to read and understand the content before the next slide appears.

    Using ARIA Roles for Screen Reader Compatibility

    ARIA roles help screen readers understand the structure and behavior of a slideshow. They provide extra information about how it’s organized and how users can interact with it.

    Best Practices:

    • Role Assignment: Use ARIA roles like role= "region" to define different parts of the slideshow so that screen readers can identify them quickly.
    • Live Regions: Use aria-live= "polite" to let screen readers know when a new slide has appeared, keeping users in the loop without disrupting their experience.
    • Hide Inactive Slides: Only show one slide at a time to screen readers. You can do this by adding aria-hidden= "true" to the slides that aren’t currently visible.

    Poor Color Contrast

    Even with the best intentions, it’s easy to fall into some design traps that can hurt accessibility. If the text on your slides blends into the background, users with low vision will have a hard time reading it.

    Best Practices:

    • High Contrast Text(WCAG SC 1.4.3): Make sure there’s plenty of contrast between the text and background. For example, white text on a dark background or black text on a light background works well. Aim for a contrast ratio of at least 4.5:1 for standard text and 3:1 for larger text, as recommended by WCAG. You can use color contrast checkers to make sure your text stands out against the background.

    Testing for Accessibility

    Once you’ve added accessibility features, testing is critical to making sure everything works as it should. There are a few easy ways to test your slideshows:

    Ways to Test:

    • Use a Screen Reader: Try out your slideshow with popular screen readers like NVDA (NonVisual Desktop Access) or JAWS (Job Access With Speech) to see if everything is being read in the correct order and labeled correctly.
    • Keyboard Navigation: Go through your slideshow using only your keyboard to make sure you can interact with all the buttons and slides.
    • Automated Tools: Use tools like WAVE or the Google Lighthouse browser feature to check for common accessibility issues like missing alt text or incorrect ARIA roles.

    Final Thoughts

    Making your slideshows and carousels accessible might take a little extra effort, but it’s totally worth it. Not only will it make your site more inclusive, but it’ll also create a smoother experience for all your users. From ensuring easy keyboard navigation to adding meaningful labels and controlling autoplay features, each step brings you closer to a more accessible website.

    So, the next time you’re adding a slideshow to your site, remember—accessibility isn’t just a nice-to-have; it’s a must-have! With a bit of planning and regular testing, you can create slideshows that everyone can enjoy.

    Are you ready to make sure your website is accessible? Then, schedule an ADA Strategy Briefing with the web accessibility experts at 216digital. 

    Greg McNeil

    September 23, 2024
    How-to Guides
    Accessibility, ADA Compliance, Carousels, digital accessibility, Slideshowes, WCAG, Web Accessibility, web development
  • WCAG: Web Accessible Coding 101

    Creating an inclusive online experience is more important than ever in today’s digital world. Accessible coding isn’t just a nice-to-have; it’s a must-have. But what does accessible coding mean, and why should you care? In this article, we’ll dive into the basics of accessible coding, explore seven fundamental principles with examples, and explain why following these guidelines benefits everyone.

    What is Web Accessibility?

    Web accessibility means making websites usable by everyone, including people who rely on assistive technologies like screen readers, people who can’t use a mouse, or those with visual or cognitive impairments. The Web Content Accessibility Guidelines (WCAG) offer a framework for creating accessible content. Adhering to WCAG helps ensure that your site is user-friendly for all.

    Why Accessible Coding is Important

    Accessible coding is crucial for a variety of reasons:

    • Wider Audience Reach: By making your site accessible, you expand your audience and enhance user experience for everyone.
    • SEO Benefits: Accessibility often overlaps with good SEO practices, boosting your website’s visibility.
    • Legal Requirements: Laws like the ADA in the U.S. require websites to be accessible, protecting you from potential legal issues.

    Now let’s dive into seven core principles of accessible coding and see how you can implement them in your website’s code.

    1.Provide Alt Text for Non-Text Components

    Alt text (short for “alternative text”) is one of the most basic, yet essential, components of web accessibility. According to WCAG 2.1 SC 1.1.1 (Non-text Content), it serves as a textual description for images and non-text content, enabling users who rely on screen readers to understand what the visual content represents.

    Why Alt Text is Important:

    • Screen Reader Accessibility: People with visual impairments use screen readers that read aloud the alt text. If an image lacks alt text, the user will miss out on important information.
    • SEO Benefits: Alt text improves SEO by giving search engines more information about the content of your images. Search engines can’t “see” images, but they can index alt text, helping your site rank better in image search results.

    Best Practices for Writing Alt Text:

    • Be Descriptive and Specific: Describe the content and purpose of the image. For example, instead of just saying “image of a tree,” say, “A large oak tree in a park during autumn.”
    • Keep it Concise: Alt text should typically be no longer than 125 characters. This keeps the description brief while still conveying necessary information.
    • Use Empty Alt Attributes for Decorative Images: For images that serve a purely decorative purpose (i.e., they don’t convey information or serve a functional purpose), use an empty alt attribute (alt=””). This prevents screen readers from wasting time on irrelevant content.

    Example:

    <img src="award-ceremony.jpg" alt="CEO receiving the 'Best Company Award' at the 2024 Business Awards" />

    In this example, the alt text describes the image in a way that conveys its significance. This provides context for users who cannot see the image and helps them understand its role on the page.

    For purely decorative images that don’t add meaning, you would use an empty alt attribute:

    <img src="border-decoration.png" alt="" />

    For more information about Alt text for images, check out our article Understanding Image Alt Text Descriptions.

    2. No Keyboard Traps

    Keyboard accessibility is critical for users who cannot use a mouse and instead rely on keyboard navigation. “Keyboard traps” occur when users get stuck in a particular interactive element (such as a form field or a modal window) and can’t navigate out using the keyboard alone.

    According to WCAG SC 2.1.1 Keyboard, websites need to be fully navigable using just a keyboard. This means that all buttons, links, and forms should be reachable and usable without a mouse. If a site doesn’t meet this standard, it can exclude many users and make it less accessible.

    How to Prevent Keyboard Traps:

    • Ensure All Interactive Elements Are Focusable: Elements like buttons, form fields, and links must be easily accessible via the keyboard’s “Tab” key.
    • Provide a Clear Way to Escape Modals: If using pop-ups or modal windows, ensure that users can exit using keyboard controls, typically the “Escape” key.

    Example:

    <a href="submit.html" id="submit-btn" tabindex="0">Submit</a>

    This code ensures that the “Submit” button can be accessed via keyboard. The tabindex="0" attribute allows it to be included in the natural tab order of the page.

    3. Allow Users to Resize Text

    People with visual impairments often need to increase the text size on websites. Accessible websites allow users to resize text up to 200% without breaking the page layout or losing content.

    How to Implement Text Resizing:

    • Use Relative Font Sizes: Avoid using fixed units like px for font size. Instead, use relative units such as em or percentages (%). This ensures that text can scale properly.
    • Test Text Scaling: After implementing relative font sizes, test your site by increasing text size to 200% in different browsers to ensure the content remains legible and the layout doesn’t break.

    Example:

    body {
    font-size: 100%; /* Base font size that scales */
    }
    h1 {
        font-size: 2em; /* 200% of the body text size */
    }

    In this example, the body text is set at a flexible 100%, and the headings use a relative size (2em) that will scale based on the user’s settings.

    4. Avoid Seizure Triggers

    Flashing elements or rapid changes in brightness can trigger seizures in people with photosensitive epilepsy. The WCAG SC 2.3.1 recommends that content should not flash more than three times per second.

    How to Prevent Seizure Triggers:

    • Avoid Fast Animations: If you need animations, make sure they don’t flash rapidly or use extreme changes in brightness.
    • Limit Flashing to Below 3 Hz: Ensure that any flashing or blinking elements do not exceed three flashes per second.

    Example:

    /* Safe animation with no rapid flashing */
    @keyframes safe-flash {
        0%, 100% { opacity: 1; }
        50% { opacity: 0.5; }
    }
    .flash-warning {
        animation: safe-flash 2s infinite;
    }

    This animation fades in and out at a safe pace, avoiding any rapid flashing that could trigger seizures.

    5. Follow a Logical Reading and Code Order

    Users who rely on screen readers navigate websites based on the underlying HTML code order, which means the structure of your code must match the logical flow of the content.

    According to WCAG Success Criterion 2.4.3, websites should be designed to allow users to navigate easily using links, headings, and other navigation tools. This means your website should allow users to effortlessly find what they’re looking for without feeling lost.

    How to Implement a Logical Code Order:

    • Use Semantic HTML Elements: Elements like <header>, <nav>, <main>, and <footer> create a well-structured HTML document that is easy for screen readers to understand.
    • Organize Content in a Meaningful Way: Ensure that headings, paragraphs, and sections appear in the correct order in your code, as this will directly impact the reading experience for users with assistive technology.

    Example:

    Here, the content is organized in a logical structure, making it easier for screen readers to understand and navigate.

      <header>
        <h1>Welcome to Our Store</h1>
        <nav>
            <ul>
                <li><a href="#home">Home</a></li>
                <li><a href="#shop">Shop</a></li>
                <li><a href="#contact">Contact Us</a></li>
            </ul>
        </nav>
    </header>
    <main>
        <section id="shop">
            <h2>Shop Our Latest Collection</h2>
            <p>Browse our new products for this season.</p>
        </section>
    </main>
    <footer>
        <p>&copy; 2024 Our Store</p>
    </footer>
    

    6. Use Headings Appropriately

    Headings are critical for organizing content and allowing users to quickly scan and understand the page structure. Screen readers rely on headings to navigate through content, making proper heading hierarchy essential.

    Best Practices for Headings:

    WCAG SC 1.3.1 Info and Relationships requires that content structure and relationships be programmatically determined or available in text. Proper use of headings and a clear content structure ensure that users can navigate and understand the content more easily.

    • Use Headings to Structure Content: Use <h1> for the main title of the page, <h2> for section titles, and so on. Don’t skip heading levels (i.e., don’t jump from <h1> to <h3>).
    • Avoid Using Headings Solely for Styling: Headings should not be used just to make text look bigger or bolder. Use them to represent the content hierarchy.

    Example:

    <h1>Guide to Accessible Coding</h1>
    <h2>Why Accessibility Matters</h2>
    <h3>Legal Requirements</h3>
    <h3>Improved User Experience</h3>

    In this example, the headings follow a logical order, making the content easy to navigate for users with screen readers.

    7. Use HTML Tags That Make Websites Accessible

    HTML provides several built-in tags that make websites more accessible. Using these elements correctly ensures that assistive technologies can understand and interact with the content.

    Key Accessible HTML Elements:

    • <label>: Associates a form field with a text description, making it easier for screen readers to understand.
    • <button>: Creates a clickable button that is accessible via keyboard and screen readers.
    • ARIA Attributes: These attributes, such as aria-label and aria-required, provide additional context for assistive technologies.

    Example:

    <form>
        <label for="email">Email Address:</label>
        <input type="email" id="email" name="email" aria-required="true">
    </form>

    In this example, the <label> tag clearly associates the input field with its description, while the aria-required="true" attribute informs screen readers that the field is mandatory.

    Don’t Just Code—Create a Welcome Mat for the Web

    Creating accessible websites isn’t just about meeting guidelines—it’s about making sure everyone has equal access to information and services online. Accessible coding improves user experience for everyone and can even boost your site’s search engine ranking. Plus, it shows that you care about all your users.

    By following these principles and using the resources provided, you can build websites that are welcoming and usable for everyone. Keep these guidelines in mind as you code, and your website will be a better place for all its visitors!

    For more information on web accessibility and coding best practices, you can visit the WCAG website.

    Greg McNeil

    September 10, 2024
    How-to Guides
    digital accessibility, How-to, WCAG, WCAG Compliance, Web Accessibility, web development
  • How to Implement ARIA Landmarks and Roles for Better Accessibility

    For users of assistive technologies, accessing and interacting with websites can be difficult if the proper structure and cues aren’t in place. This is where ARIA (Accessible Rich Internet Applications) landmarks and roles come in handy. Implementing ARIA landmarks and roles can significantly improve your website’s accessibility, helping users navigate more easily and interact with web elements effectively. If you’re new to ARIA, don’t worry! This guide will walk you through ARIA landmarks and roles, why they matter, and how to implement them step-by-step.

    What Is ARIA and Why Is It Important?

    ARIA is a set of HTML attributes intended to make webpages easier to navigate for people who rely on assistive technology, such as screen reading software. These attributes help bridge gaps in standard HTML that might not convey sufficient meaning to people with disabilities.

    By using ARIA, developers can label, describe, and define the functionality of elements in ways that ensure everyone has a better user experience. Regarding web accessibility, ARIA attributes are recommended in some cases by the Web Content Accessibility Guidelines (WCAG), which provide standards to help websites comply with accessibility requirements.

    ARIA landmarks and roles are two essential aspects of making sure your website content is accessible for all users to understand and interact with.

    ARIA Landmarks: What Are They?

    ARIA landmarks are unique markers you can add to different sections of your webpage to make navigation easier for users with disabilities. These landmarks help people who use screen readers understand the structure of a webpage and quickly jump to different sections. Think of them as signposts, making it clear where key sections—like the header, main content, navigation, and footer—are located.

    The major ARIA landmarks include:

    • <header>: Identifies the top section of the webpage.
    • <main>: Indicates the main content of the page.
    • <nav>: Points to the area that contains navigational links.
    • <footer>: The bottom section of the webpage.

    Why Are ARIA Landmarks Important?

    ARIA landmarks are invaluable for users with visual or motor impairments who use the keyboard or screen reader to navigate the web. They allow users to skip repetitive elements (like navigation bars) and jump directly to the content they’re looking for. Without these landmarks, a user would have to listen to every single line of the page to figure out where the main content starts or how to get to the footer. Using ARIA landmarks ensures that your website is easy to navigate for everyone.

    How to Implement ARIA Landmarks Step-by-Step

    Now that you understand the importance of ARIA landmarks let’s look at how to implement them in your website’s code. The good news? Adding ARIA landmarks is simple and can be done using standard HTML elements.

    Adding the Header Landmark

    The <header> element is used to define the global top section of your page, which typically contains things like the website logo, title, or main navigation links. Here’s an example of the correct usage of the HTML5 <header> region:

    <header>

    <h1>My Cool Website</h1>
    <h1>My Cool Website</h1>
      <nav>
        <ul>
          <li><a href="/">Home</a></li>
          <li><a href="/about">About</a></li>
          <li><a href="/products">Products</a></li>
        </ul>
      </nav>
    </header>

    The Main Landmark

    The <main> element is crucial because it defines the primary content of the page. The <main> element, along with a skip link, can allow users of assistive technology to skip past repetitive content such as the navigation:

    <main role="main">
      <h2>Main Content</h2>
      <p>This is the most important part of the page.</p>
    </main>

    By using role=”main”, you’re ensuring that screen readers can quickly identify and jump to the core content of your page. Only one main landmark should be used per page.

    Using the Navigation Landmark

    The navigation area of your website should be easy to identify and skip if necessary. You can use the <nav> element or the ARIA role, but you do not need to use both:

    <nav>
      <ul>
        <li><a href="#section1">Section 1</a></li>
        <li><a href="#section2">Section 2</a></li>
      </ul>
    </nav>
    <div role="navigation">
      <ul>
        <li><a href="/products">Products</a></li>
        <li><a href="/about">About Us</a></li>
      </ul>
    </div>

    With the navigation region, you’re clearly marking the section of the page that contains links for navigating to other parts of the site.

    Adding the Footer Landmark

    Finally, the <footer> element typically contains secondary content, such as copyright information or additional links. Adding a landmark here helps screen reader users know when they’ve reached the end of the page:

    <footer role="contentinfo">
      <p>&copy; 2024 Your Company</p>
    </footer>

    In this case, role= "contentinfo" tells screen readers that this section provides supplementary information about the website.

    ARIA Roles: What Are They?

    ARIA roles go beyond marking sections of the page—they describe the functionality of specific elements. By using ARIA roles, you’re defining how an element should behave or be interacted with, especially when using assistive technologies.

    Some commonly used ARIA roles include:

    • “button”: Makes non-biased elements like <div> behave like a button.
    • “dialog”: Defines a pop-up dialog window.
    • “alert”: Marks an element as an important alert that needs immediate attention.

    Why Are ARIA Roles Important?

    ARIA roles give more meaning to non-standard HTML elements. For example, if you create a custom button using a <div> instead of the traditional <button> element, a screen reader might not recognize it as a button. By assigning it an ARIA role, you ensure it’s interpreted correctly, making the interaction more intuitive and accessible.

    How to Implement ARIA Roles Step-by-Step

    Let’s check out some examples of proper ARIA implementation.

    Creating a Custom Button

    If you have a custom button element (like a <div> styled as a button), you can add the role="button" to make sure it’s recognized as an interactive button by screen readers:

    <div role="button" tabindex="0" onclick="submitForm()">Submit</div>

    The ARIA role “button” tells assistive technology to announce this element as a button, and the “tabindex” attribute makes the element focusable via the keyboard. However, it’s always best to use the correct semantic HTML5 <button> tag whenever possible.

    Adding a Dialog Role

    For models or pop-up windows, you can use the role= "dialog" to make them accessible:

    <div role="dialog" aria-labelledby="dialogTitle" aria-describedby="dialogDescription">
      <h2 id="dialogTitle">Confirmation</h2>
      <p id="dialogDescription">Are you sure you want to delete this file?</p>
      <button onclick="closeDialog()">Cancel</button>
    </div>

    The aria-labelledby and aria-describedby attributes help give context to the dialog box for users relying on assistive technologies.

    Creating an Alert

    If you need to display important, time-sensitive information—like an error message or form feedback—you can use the role= "alert":

    <div role="alert">
      <p>Error: The "password" field is required.</p>
    </div>

    This role makes sure that screen readers announce the alert immediately, ensuring the user doesn’t miss critical information.

    Going Beyond ARIA: Continue Your Accessibility Journey

    The HTML markup of your website is far more critical than just defining the visual style of the site. It is used by screen reading software, assistive technologies, and keyboard navigation to ensure users have easy access to content. SEO crawlers also use it to determine the accuracy and relevance of your content.

    By adding landmarks like header, main, navigation, and footer, and using roles like button, dialog, and alert, you’ll not only meet the accessibility standards outlined by WCAG, but you’ll also create a more user-friendly website for everyone.However, this is just one piece of the web accessibility puzzle.

    Team Up with 216digital

    At 216digital, we understand that keeping up with ADA compliance and accessibility best practices can be challenging. That’s why we’re here to help. We specialize in helping businesses achieve and maintain ADA compliance with expert guidance and actionable strategies. Schedule an ADA briefing with our experts today to learn more about how we can guide you through the complexities of accessibility, ensuring your website meets legal standards and delivers a great experience for all users. 

    Let’s make the web more accessible, together—book your ADA briefing today!

    Bobby

    September 6, 2024
    How-to Guides
    Accessibility, ADA Compliance, ARIA, How-to, WCAG, Web Accessibility, web development
  • Does WCAG Apply to Mobile Apps?

    Does WCAG Apply to Mobile Apps?

    If you’re a website owner or app developer, you’ve probably heard about WCAG (Web Content Accessibility Guidelines). But when it comes to mobile apps, you might wonder: Does WCAG apply here too? The short answer is yes! WCAG isn’t just for websites—it extends to mobile apps as well. Let’s dive into why WCAG is important for mobile apps, what it means for accessibility, and how to ensure your app meets these guidelines.

    What is WCAG, and Why Does it Matter?

    WCAG, developed by the World Wide Web Consortium (W3C), provides guidelines to make web content more accessible for everyone, particularly people with disabilities. These guidelines help ensure that users with visual, auditory, motor, or cognitive impairments can interact with websites—and, as it turns out, mobile apps—with ease.

    When WCAG was first introduced, it focused on websites, but as technology evolved, so did our understanding of accessibility. With the rise of mobile apps, it’s clear that WCAG also applies to them. Whether you’re building an e-commerce app, a social media platform, or a mobile version of your website, adhering to WCAG is crucial for staying compliant with accessibility standards and avoiding legal issues.

    Does WCAG Apply to Mobile Apps?

    Yes, WCAG applies to mobile apps. While WCAG wasn’t initially designed with mobile apps in mind, its principles are just as relevant in the mobile space. The guidelines are technology-agnostic, meaning they can be applied to any digital content, including mobile apps.

    Mobile apps, like websites, must be accessible to everyone, and the same types of barriers that exist on websites—like unreadable text, poor color contrast, or unclear navigation—can also affect mobile apps. That’s why WCAG compliance is essential for mobile app development. Not only does it help create a better user experience for people with disabilities, but it also ensures that your app is legally compliant.

    The Growing Importance of Mobile Accessibility

    Mobile devices have become an essential part of our daily lives, with more people accessing information and services via apps than ever before. This makes it even more important to ensure that mobile apps are accessible. In fact, a significant portion of users rely on mobile devices as their primary way of accessing the internet, including people with disabilities. Ensuring your app meets accessibility standards isn’t just good practice; it’s a way to reach a broader audience.

    Failing to consider accessibility in mobile apps can result in lost users, bad reviews, and even legal consequences. There have been several lawsuits filed in the U.S. where businesses were held accountable for not providing accessible mobile experiences. By following WCAG, you reduce the risk of these issues and open your app to a more diverse audience.

    How WCAG Applies to Mobile Apps

    WCAG guidelines revolve around four core principles: Perceivable, Operable, Understandable, and Robust (often abbreviated as POUR). These principles are crucial when designing both websites and mobile apps.

    1. Perceivable: Information and user interface components must be presented in ways that users can perceive. For mobile apps, this means ensuring that text is readable, images are described through alt text, and media elements are captioned or have transcripts available.
    2. Operable: Users must be able to interact with all interface elements using various input methods, such as screen readers or voice commands. In mobile apps, this could include ensuring that buttons are large enough to be tapped easily and that the app works with assistive technologies like voice control or switch access.
    3. Understandable: The interface must be easy to understand and navigate. This is especially important for mobile apps, where the small screen size can make navigation more difficult. Make sure that users can easily understand how to use your app, with clear instructions and intuitive design elements.
    4. Robust: The app must be compatible with current and future technologies. This includes ensuring that your app works well across different devices, platforms, and with assistive technologies.

    Mobile App Accessibility Checklist

    Now that we’ve established that WCAG does apply to mobile apps, how do you ensure that your app is compliant? Here’s a mobile app accessibility checklist to get you started:

    Text and Readability

    1. Text Resizing: Make sure your text can get bigger without messing up the layout. This is part of WCAG 1.4.4 (Resize Text), which means users should be able to increase text size up to 200% without losing content or functionality.
    2. High Contrast: Use colors that are easy to read against each other, like dark text on a light background. This helps everyone, including those with vision problems. WCAG 1.4.3 (Contrast Ratio) suggests a contrast ratio of at least 4.5:1 for normal text and 3:1 for larger text.
    3. Alternative Text: Always include a description for images, icons, and buttons. This helps screen readers explain what’s on the screen to people who can’t see the images. This follows WCAG 1.1.1 (Non-Text Content).

    Keyboard and Assistive Technology Compatibility

    1. Keyboard Accessibility: Make sure all parts of your app can be used with just a keyboard. This is covered by WCAG 2.1.1 (Keyboard), ensuring that users who can’t use a mouse can still navigate your app.
    2. Assistive Technology: Check that your app works well with tools like screen readers, voice controls, and switches. This is important for WCAG 4.1.2 (Name, Role, Value), which ensures that assistive technologies can interpret user interface elements.
    3. Screen Reader Testing: Test your app with popular screen readers like VoiceOver (for iPhones) and TalkBack (for Android phones) to make sure they work well together.

    Navigation and Interaction

    1. Consistent Navigation: Keep navigation easy and the same across different screens. This is part of WCAG 3.2.3 (Consistent Navigation), which helps users get around without getting lost.
    2. Touch Targets: Make sure buttons and icons are big enough for everyone to tap easily. WCAG 2.5.5 (Target Size) recommends making touch targets at least 44×44 pixels.
    3. Simple Gestures: Avoid using complex gestures like multi-finger swipes without offering simpler options. WCAG 2.5.1 (Pointer Gestures) suggests providing alternatives for complex gestures.

    Audio and Video Content

    1. Captions: Add captions to all your videos so people who can’t hear well can still understand what’s being said. This is part of WCAG 1.2.2 (Captions (Pre-recorded)).
    2. Transcripts: Include transcripts for audio content and podcasts. This is a text version of the audio that helps people who are deaf or hard of hearing, covered by WCAG 1.2.1 (Audio-only and Video-only (Prerecorded)).
    3. Playback Controls: Let users control the audio playback, including volume and speed, and make sure they can pause or stop it. This aligns with WCAG 1.4.2 (Audio Control).

    Color and Contrast

    1. Color Contrast: Ensure there’s a strong contrast between text and background colors to help users with color blindness or vision problems. Aim for a contrast ratio of at least 4.5:1 for regular text and 3:1 for large text, as recommended by WCAG 1.4.3 (Contrast Ratio).
    2. Avoid Color Alone: Don’t use color as the only way to show important info. For example, if you use red to highlight an error, also include text to explain it. This follows WCAG 1.4.1 (Use of Color).

    Error Identification and Recovery

    1. Error Highlighting: Clearly show when something goes wrong, like a missing form field, and give tips on how to fix it. This is part of WCAG 3.3.1 (Error Identification) and 3.3.3 (Error Suggestion).
    2. Clear Error Messages: Make sure error messages are easy to understand, not full of technical jargon. This helps users fix mistakes, as outlined in WCAG 3.3.3 (Error Suggestion).
    3. Easy Recovery: Allow users to fix mistakes without starting over. For example, let them undo actions or correct errors easily. This is covered by WCAG 3.3.4 (Error Prevention (Legal, Financial, Data)).

    Test with Real Users

    1. User Testing: Even if you follow all the WCAG guidelines, it’s crucial to test your app with real users who use assistive technologies. Their feedback is invaluable for ensuring your app is truly accessible.
    2. Keep Improving: Use feedback from user testing to make your app better. Keep updating and checking your app to make sure it stays accessible as you add new features.

    The Benefits of Accessible Mobile Apps

    Making your mobile app accessible is not just about complying with regulations—it’s about providing a better user experience for everyone. Here are some key benefits:

    • Wider Audience: Accessible apps reach a broader audience, including users with disabilities who may not be able to use apps that don’t meet WCAG guidelines.
    • Improved Usability: Many accessibility improvements, like clearer navigation and larger touch targets, make your app easier to use for all users, not just those with disabilities.
    • Avoiding Legal Risk: Compliance with WCAG helps you stay on the right side of web compliance laws, reducing the risk of lawsuits related to accessibility.
    • Better Reputation: Being proactive about accessibility can enhance your brand’s reputation and show your commitment to inclusivity.

    Final Thoughts

    In the digital age, mobile apps are a key part of how we interact with the world, and making sure they’re accessible is crucial for providing an inclusive experience. WCAG does apply to mobile apps, and by following the guidelines, you can create apps that are usable by everyone, regardless of their abilities. Whether you’re just starting out or you’re improving an existing app, using the mobile app accessibility checklist can help ensure that your app is WCAG-compliant and ready to serve all users.

    Remember, accessibility isn’t just about following the law—it’s about doing the right thing for your users and your business. To learn more about becoming accessible and staying compliant, schedule an ADA briefing with 216digital today. We’re here to help you take the next steps!

    Greg McNeil

    August 27, 2024
    WCAG Compliance
    digital accessibility, mobile apps, WCAG, WCAG Compliance, Web Accessibility
  • Understanding WCAG for Better Digital Compliance

    Understanding WCAG for Better Digital Compliance

    The World Wide Web is an interconnected network of knowledge accessible to anyone with an internet connection. However, the term ‘anyone’ isn’t always accurate. Some individuals, particularly those with disabilities, may find it challenging to access information and services online.

    Fortunately, the Web Content Accessibility Guidelines (WCAG) are here to change this. WCAG can help websites follow the best practices of accessible design and eliminate accessibility barriers that could expose your business to the risk of legal action.

    But what is WCAG — and how does it apply to your online business? In this post, we answer these questions and provide a few tips for making your web content WCAG-compliant.

    The World Wide Web Consortium

    The World Wide Web Consortium (W3C) is an international organization committed to improving the web. In 1997, the W3C launched the Web Accessibility Initiative (WAI) with the goal of providing strategies, guidelines, and resources to make the web accessible to people with disabilities. This initiative includes technical specifications for HTML, CSS, XML, and other technologies used to build websites.

    Out of the WAI was born the Web Content Accessibility Guidelines or WCAG.

    What is WCAG?

    The Web Content Accessibility Guidelines, commonly known as WCAG, are a set of recommendations designed to make web content more accessible, primarily for people with disabilities. However, following these guidelines can also make your web content more accessible to all users, regardless of the device they’re using or their internet access circumstances.

    The initial version of WCAG, WCAG 1.0, was released in 1999 with 14 guidelines. Since then, it has undergone significant revisions to better address the needs of various users and keep pace with rapidly evolving technologies. The most recent version at the time of this writing, WCAG 2.1, was published in 2021. However, the WAI plans to introduce WCAG 2.2 in the fall of 2023. Learn more about WCAG 2.2 and the future of accessibility standards.

    WCAG Structure

    WCAG is organized around four fundamental principles, which state that all content must be Perceivable, Operable, Understandable, and Robust (POUR). These four principles are expanded upon by supporting guidelines and further divided into distinct Success Criteria. These Success Criteria serve as precise and verifiable requirements for accessibility.

    An Example of WCAG Success Criteria 

    Success Criterion 1.1.1 Non-text Content states: “All non-text content presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below…”

    This Success Criterion is one of the Success Criteria under Guideline 1.1 Text Alternatives: “Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols, or simpler language.”

    This Guideline is one of the Guidelines under Principle 1. Perceivable: “Information and user interface components must be presentable to users in ways they can perceive.”

    WCAG Conformance Levels

    WCAG success criteria are organized into three levels of conformance: Level A, Level AA, and Level AAA. Each Success Criterion is assigned a conformance level of A, AA, or AAA, with each Level including all success criteria from the lower levels.

    For instance, Level AA includes all Level A success criteria, while Level AAA includes both Level A and AA success criteria. To qualify as meeting a certain conformance level, all content on a website must fully meet at least that Level.

    While Level A conformance makes a website accessible, Level AA conformance of WCAG 2.0 or 2.1 is the most common. Websites that meet the Level AA requirements of the current version of WCAG are generally considered reasonably accessible to most users with disabilities.

    Achieving Level AA conformance means satisfying all Level A and AA Success Criteria. However, it’s important to note that meeting Level AAA is optional as it’s impossible for some content to meet all Level AAA Success Criteria.

    Understanding How WAI Maintains and Updates WCAG

    The WAI regularly updates the WCAG to keep up with advancements in technology and user needs, ensuring the guidelines remain relevant and effective.

    The WAI organizes this process through milestones, which are as follows:

    1. Working Draft: The WAI team publishes the document as a Working Draft to ask for review and input from the community. The team updates the draft based on feedback. Usually, multiple Working Drafts of a technical report are published.
    2. Wide Review Working Draft: Once all the comments and technical requirements have been addressed, it provides the complete document for community review. At this stage, members of the public are invited to leave comments.
    3. Candidate Recommendations: The main purpose of the Candidate Recommendation is to ensure that the technical report can be implemented. At this stage, developers are encouraged to use the new version of WCAG in their projects.
    4. Proposed Recommendation:  After implementing each feature of the technical report, the W3C announces it as a Proposed Recommendation for W3C membership endorsement
    5. W3C Recommendation: Once there is significant support for a new version of WCAG from the W3C Members, the W3C Director, and the public, it becomes an official W3C Recommendation. 

    It’s important to understand that WCAG is a living document, consistently updated to meet changing technology and digital accessibility needs. Hence, reaching each milestone takes time. WCAG needs to apply to different types of digital content and be reasonably future-proof.

    But which version of WCAG should you use to test your content?

    Which Version of WCAG Should I Use To Test My Content?

    WCAG offers businesses a straightforward way to test their web content for accessibility issues. Each version of WCAG is designed for backward compatibility, including all previous guidelines and adding new ones. While recent versions of WCAG extend the requirements of older versions, the old standards still apply.

    But which version of WCAG should you use for testing? When deciding which version of WCAG to use for testing your content, it’s generally recommended to use the latest version. Using the most recent version will ensure your website complies with the Americans with Disabilities Act (ADA) and other nondiscrimination laws, mitigating the risk of frivolous ADA lawsuits.

    Is WCAG a Legal Requirement?

    While WCAG is not legally binding in every country, many governments require compliance with its guidelines to ensure digital accessibility. For instance, in the US, federal websites must meet WCAG 2.1 Level A and AA requirements under Section 508 of the Rehabilitation Act.

    Similarly, Title III of the ADA applies to private businesses but doesn’t explicitly mention WCAG or provide technical standards for online content. However, the Department of Justice (DOJ) published guidance in 2022 confirming its position that the ADA applies to business websites, stating:

    “…the Department has consistently taken the position that the ADA’s requirements apply to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web.”

    – US Department of Justice | Guidance on Web Accessibility and the ADA (2022)

    The Rise of ADA Web Compliance Lawsuits

    Failure to meet these standards can expose businesses to legal challenges, as was the case with Domino’s Pizza in 2019. More recently, there has been a sharp increase in lawsuits related to website accessibility. For example, in 2022 alone, there were 2,387 web accessibility lawsuits filed in Federal Court and California State Court under the Unruh Act. This number doesn’t include the rising number of ADA legal complaints and ADA compliance demand letters sent to businesses with non-accessible websites.

    While WCAG conformance might not be legally required elsewhere, it’s still considered a best practice and can significantly improve the user experience for all visitors.

    Understanding What Conformance Means

    WCAG conformance means that your website meets the criteria set by the WCAG guidelines. This involves more than just ticking off a list of guidelines; it means ensuring your website is accessible and usable for people with various disabilities.

    W3C’s Understanding Conformance explains: “Conformance to a standard means that you meet or satisfy the ‘requirements’ of the standard.”

    There are five requirements for conformance, per W3C:

    1. Conformance Level:  Websites must fully meet Level A, AA, or AAA levels.
    2. Full Pages: Conformance and conformance levels account for the entire website or web page. It does not exclude a part of the website or a web page or evaluate each page individually.
    3. Complete Process:  If a web page is part of a multi-page process where a sequence of steps must be completed to accomplish an activity, all web pages must conform at the specified Level or better. Conformance can only be achieved if all pages in the sequence of steps conform at that Level or better.
    4. Only Accessibility-Supported Ways of Using Technologies: Accessibility-supported technologies must be used to satisfy the success criteria. Any information or functionality not supported must also be available in a way that is accessibility supported.
    5. Non-interference:  If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, they must not prevent users from accessing the rest of the page. Additional requirements may also apply.

    For more information, review W3C’s Understanding Conformance.

    Building a Strategy for WCAG Conformance 

    Every online business should commit to web accessibility. Thankfully, WCAG makes this process more manageable. By planning to test your content against WCAG Level AA, you can find and address barriers affecting your users.

    At 216digital, we’re dedicated to helping businesses achieve WCAG conformance. We can help develop a strategy to integrate WCAG 2.1 compliance into your development roadmap on your terms so you can focus on your other tasks.

    Would you like to know where your business stands today? Schedule a complimentary ADA Strategy Briefing with 216digital to get a free scan of any URL and uncover accessibility issues on your site.

    Greg McNeil

    July 10, 2023
    WCAG Compliance
    Accessibility, ADA Compliance, ADA non-compliance, ADA Website Compliance, WCAG, Website Accessibility
  • What to Expect from WCAG 2.2

    What to Expect from WCAG 2.2

    Are you an online business or website owner? If so, you must be aware of the critical changes in the  Web Content Accessibility Guidelines (WCAG) 2.2! The World Wide Web Consortium (W3C) is expected to release the latest version of WCAG in May 2023. So stay ahead of the curve and ensure your website remains accessible to all users, including those with disabilities. Here’s what you need to know about the proposed changes — and how they will affect your current WCAG compliance. And remember, when WCAG 2.2 goes live, 216digital will be here to help.

    Why is WCAG Changing?

    WCAG is a set of guidelines designed to help make web content more accessible to people with disabilities. However, as technology and user preferences change, so must WCAG’s standards. Each new standard introduced is developed by the Web Accessibility Initiative (WAI). In 2021, WAI announced they were starting to work on the draft for WCAG 2.2, which is finally expected to be released sometime next month.

    WCAG can be changed to add new success criteria or to change a current guideline’s conformance level. But, it will not remove any guidelines or change any language. Currently, WCAG 2.2 is based on the same three conformance levels as the previous versions: Level A, AA, and AAA.

    Level A

    Level A is the lowest level of conformance and the easiest to achieve with minimal impact on a website’s structure or design. It allows websites to be broadly accessible as it addresses the most basic access issues.

    Level AA 

    By meeting the success criteria for Level AA, websites are considered reasonably accessible as they offer a higher level of conformity than Level A. AA is most often used as the compliance standard in lawsuits and is usable for most people.

    Level AAA

    Level AAA is the highest level of conformance and the most difficult to achieve. It is not often used as a goal to strive toward since it is not feasible for most websites to have the resources to meet this level.

    What’s Changing In WCAG 2.2?

    WCAG 2.2 introduces nine new success criteria along with minor changes to the instructions accompanying several established guidelines. However, each of these criteria is still up for feedback and changes, so there’s no guarantee that all of them will make it into the final version of WCAG 2.2.

    Here’s a quick overview of the new guidelines — and how each one can help address web accessibility issues:

    Guideline 2.4 Navigable

    2.4.11 Focus Appearance (Minimum)

    Level AA

    Focus Appearance builds on two existing WCAG criteria, specifying the minimum requirements for focus indicators. The new guideline ensures that keyboard focus indicators are visible and easily distinguishable. They must have a clear border, are not obscured by other content, and have at least a color contrast ratio of 3:1 against the unfocused state and all adjacent colors.

    The intent of WCAG 2.4.11  is to help low-vision users who use a keyboard for navigation. Users can quickly tell where they are on a page by ensuring the current focus point is visible.

    2.4.12 Focus Not Obscured (Minimum)

    Level AA

    Knowing the current focus point is essential for sighted users who use a keyboard or keyboard-like device. However, sticky headers, pop-ups, and other content can sometimes obscure focused elements while a user is browsing.

    However, Criterion 2.4.12 requires user interface components not to be entirely hidden from other content on the page. This lets users easily track the current focus point and avoid confusion.

    2.4.13 Focus Not Obscured (Enhanced)

    Level AAA

    Similar to 2.4.12, 2.4.13 requires that no part of the focus indicator is hidden by other content.

    Guideline 2.5 Input Modalities

    2.5.7 Dragging Movements

    Level AA

    Drag and drop movements can be difficult and error-prone for many website users. Therefore, WCAG 2.5.7 requires that any functionality that uses a dragging movement for operation can also be achieved in other ways, like clicking. For example, a user could use a single tap, double tap, long presses, or path-based gestures instead of dragging an item. However, a dragging action is allowed when it is essential to the functionality of the content.

    2.5.8 Target Size (Minimum)

    Level AA

    When buttons and other clickable elements are small, they can be challenging to interact with for people with fine motor impairments. The purpose of 2.5.8 is to ensure that when users select a target with a mouse or other device, they can do so easily without activating other nearby targets. Therefore, all clickable elements, such as links, must be at least 24 by 24 CSS pixels in size and spacing between adjacent targets.

    2.5.8 provides a level AA alternative to 2.5.5: Target Size (Enhanced), which was introduced as part of WCAG 2.1. However, 2.5.5 requires the target size for all clickable elements to be at least 44 by 44 CSS pixels.

    Guideline 3.2 Predictable

    3.2.6: Consistent Help

    Level A

    The goal of 3.2.6 is to ensure that all users can easily find help when completing tasks on a web page. For example, suppose a help feature — such as search bars and help buttons — is available on multiple pages of a website. In that case, it must appear in the same relative place an order on each of the pages where it appears. This is particularly beneficial for users with cognitive disabilities or limited web experience, as they can quickly access help when needed.

    Guideline 3.3 Input Assistance

    3.3.7 Redundant Entry

    Level A

    For people with cognitive disabilities, logging into a website or mobile app can be challenging. The 3.3.7  level AA guideline tackles authentication processes that require the user to remember, manipulate, or transcribe information. Websites that use cognitive function tests must provide at least one other authentication method.

    For instance, asking users to remember a password is a standard cognitive function test. But suppose the website allows entries from password manager browser extensions. In that case, the website has provided them with a mechanism to complete the process.

    3.3.8 Accessible Authentication (Minimum)

    Level AA

    3.3.8 takes 3.37 further by not allowing any exceptions for cognitive function tests. For multi-step processes, 3.3.8 requires websites to auto-populate fields or enable users to select the information that they’ve previously entered. For example, suppose a website’s form requires the user to enter their address multiple times. In that case, the second field should either provide users with an option to select their address from the previous entry or auto-populate.

    3.3.9: Redundant Entry ( Enhanced)

    Level AAA

    Similar to 3.3.7 and 3.3.8, 3.3.9 applies to the authentication process. However, 3.3.9 is a Level AAA guideline that does not require an authentication process unless that step provides an alternative authentication process or auto-populate.

    Getting Ready for WCAG 2.2

    While the full implementation of WCAG 2.2 may still be on the horizon, it’s never too early to start preparing. Here are some steps you can take to ensure a smooth transition:

    1. Familiarize yourself with the new success criteria and understand their implications for your website.
    2. Conduct an accessibility audit to identify areas that need improvement and align with WCAG 2.2 requirements.
    3. Update your website’s design, content, and functionality to address the new criteria and improve accessibility.
    4. Train your team on the importance of web accessibility and the new guidelines to ensure consistent implementation.

    How Will the Revisions Affect My Current WCAG Compliance?

    The transition from WCAG 2.1 to 2.2 will require some adjustments to your website, particularly in the areas of navigability, input modalities, predictability, and input assistance. However, these updates are designed to build upon the existing guidelines, so your current efforts will not be wasted. By proactively addressing these changes, you’ll ensure that your website remains compliant and accessible to all users.

    When WCAG 2.2 Goes Live, We’ll Be Here to Help

    When WCAG 2.2 goes live, you can count on  216digital to help you navigate the changes and maintain an accessible website. Our expert team will assess your website, provide recommendations, and implement the necessary adjustments to ensure your website meets the latest accessibility standards. Reach out to us today by scheduling a complementary ADA Strategy Briefing so that you can embrace the future of web accessibility with confidence.

    Greg McNeil

    April 28, 2023
    WCAG Compliance
    Accessibility, ADA Compliance, ADA Website Compliance, WCAG, WCAG 2.2, Website Accessibility
  • What Are the Levels of WCAG Compliance?

    What Are the Levels of WCAG Compliance?

    When it comes to accessibility compliance, the Web Content Accessibility Guidelines (WCAG) version 2.0 is the most widely used standard worldwide. WCAG has set internationally shared standards for web content accessibility to meet the needs of individuals, organizations, and governments. Web Content applies to all content on a web page or application, including text, images, sounds, code, or markup that define a website’s structure or presentation.

    There are three levels of WCAG compliance: A, AA, and AAA. Although this distinction is essential, it can be baffling. Therefore, we will discuss what WCAG A, AA, and AAA are, what they mean for your site, and which compliance level to aim for when becoming accessible.

    Learn more about WCAG and ADA Web Accessibility Standards

    What are the WCAG Levels?

    There are three compliance levels within WCAG 2.0: A, AA, and AAA. For a website to be accessible for all users, each level’s requirments must be met. The distinction between conformance levels gives an organized structure requiring an increasingly higher standard of accessibility. The three levels provide flexibility upon different situations. For example, in complex websites or advancing technologies, to maintain a minimum level of compliance.

    WCAG Foundation Principles

    Each level of compliance is based on the same four principles of web accessibility. These principles are the foundations for content on the web and anyone wanting to use it. WCAG 2.0 guidelines follow these four principles: perceivable, operable, understandable, and robust, referred to as POUR. Therefore, to understand each WCAG level, it is essential to start with their foundation. 

    Perceivable

    A website’s information and elements must be apparent to the user, leaving nothing undetectable or invisible. Most users perceive content and elements on a website through visuals. However, sound or touch are used alternatively for those unable to. 

    Operable

    A website’s interactive elements such as controls, buttons, and navigations should be operable by all users. Users must operate the interface elements by first identifying those elements and selecting those options. Most users can interact by clicking, tapping, swiping, or rolling. However, users who cannot physically click require voice commands or other assistive devices to engage with interactive elements. 

    Understandable

    Websites must be clear and concise in presenting predictable patterns for interaction and design. Users should have no issue comprehending the meaning or purpose of the presented information, including the function of buttons or other elements on a website. Everything should have a purpose and should be recognizable to all users.

    Robust

    Content must be robust enough for users to understand the function and reliably use various assisting technologies. 

    What Do the Different WCAG Conformance Levels Mean?

    As previously mentioned, WCAG 2.0 A, AA, and AAA all have specific criteria to be met. The requirements for a website include all interactive elements, content, and presentation following four principles of POUR. WCAG does provide guidelines for each level for what an accessible website should do, each level building upon the next. However, the specific actions each website must take to be considered accessible or reach a certain level of compliance are not outlined. The most significant difference between conformance levels A, AA, and AAA is what they mean for the users of each website. 

    WCAG 2.0 Level A: Minimal Compliance

    Level A covers the basic requirements and is the minimum degree of accessibility for a website to be accessible. Basic requirements to meet Level A do not impact the design or structure of the website. Failure to fulfill will result in an inaccessible website and will be impossible or exceedingly difficult for users with disabilities to use.

    Notable WCAG 2.0 Level A success criteria include:

    • All non-text content such as audio, video, or images must have a text alternative such as an alt text within the website’s code or captions to serve as an equivalent source for information and context. 
    • Users can effectively navigate the website using only keyboard inputs.
    • Time-based media or video content must have a media alternative for text. 
    • Content and interface elements conveyed through presentation can be extracted and presented to the user in different modalities through assistive technologies or user agents.
    • Color is not used as the only visual means of conveying information, prompting a response, distinguishing an element, or indicating an action by the user.

    WCAG 2.0 Level AA: Acceptable Compliance

    Level A conformance is an excellent starting point. However, Level AA goes further by ensuring a website must be deemed usable and understandable for most people, regardless of ability. For this reason, level AA compliance has been the standard for accessibility and web accessibility laws globally, including the ADA and Section 508 in the United States. 

    Notable WCAG 2.0 Level AA success criteria include:

    • Text for content, captions, and text images can be resized without assistive technology up to 200% without loss of range of function.
    • Text or alt text is used to convey information or content rather than images with text.
    • More than one way to locate a web page within a website except when the web page is the result of a process or steps
    • Navigation elements are consistent throughout the site
    • Form fields have accurate labels

    WCAG 2.0 Level AAA: Completely Compliant

    Compliance at WCAG 2.0 is the highest level of accessibility and accommodates the maximum number of users. Unfortunately, it is also the most challenging level to achieve. While this level of compliance would be ideal, it is not necessary., W3 states they do not recommend or require Level AAA compliance for an entire website since it is impossible to achieve Level AAA from some content.

    Notable WCAG 2.0 Level AAA success criteria include:

    • Sign language interpretation for audio or video content
    • Visual presentation of text and images has a contrast ratio of at least 7:1 except for large text, logo, or visual decorative components with no significance to the content.
    • Timing is not an essential part of any activity on the website. 
    • The website does not contain anything that flashes more than three times in any one second.
    • Context-sensitive help is available.

    Can You Partially Meet a WCAG Level?

    A website must meet all of the accessibility compliance level’s guidelines. To state that a website is Level AA compliant, it must meet every requirement for both Level A and the Level AA guidelines. Therefore, if you meet the24 out of 25 requirements for Level AA, your site will still be deemed only a Level A. However, please do not use this not to try to aim for higher levels of compliance. The more accessible your site is, the better the user experience is for your users regardless of their abilities.

    What WCAG Level to Aim For

    Most websites and development teams aim to meet Level AA. The legally required level for legislation for specific sites is Level AA, including the ADA and Section 508. Suppose you want to strengthen your existing website by making it ADA compliant. In that case, it is best to accomplish the Level A criteria first before progressing to Level AA. A Level A compliance level is still more accessible than an inaccessible website.

    Closing

    Understanding the different levels of WCAG 2.0 and their requirements can serve as a guide when implementing accessibility into your website. Take the first steps towards becoming accessible. Testing and correcting accessibility issues will help better your business and mitigate expensive ADA lawsuits. 

    Integrating accessibility can seem intimidating at first, but 216digital  is here to help. If you would like more information on web accessibility or how to make your website accessible today, schedule a 15-minute complimentary consultation with our experts.

    Greg McNeil

    January 27, 2022
    WCAG Compliance
    Accessibility, WCAG, Website Accessibility, Website Accessibility Tools
Previous Page
1 … 4 5 6
216digital Scanning Tool

Audit Your Website for Free

Find Out if Your Website is WCAG & ADA Compliant













    216digital Logo

    Our team is full of expert professionals in Web Accessibility Remediation, eCommerce Design & Development, and Marketing – ready to help you reach your goals and thrive in a competitive marketplace. 

    216 Digital, Inc. BBB Business Review

    Get in Touch

    2208 E Enterprise Pkwy
    Twinsburg, OH 44087
    216.505.4400
    info@216digital.com

    Support

    Support Desk
    Acceptable Use Policy
    Accessibility Policy
    Privacy Policy

    Web Accessibility

    Settlement & Risk Mitigation
    WCAG 2.1/2.2 AA Compliance
    Monitoring Service by a11y.Radar

    Development & Marketing

    eCommerce Development
    PPC Marketing
    Professional SEO

    About

    About Us
    Contact

    Copyright 2024 216digital. All Rights Reserved.