The ARC Toolkit is a powerful accessibility tool designed to help developers and quality assurance testers identify and address accessibility issues in web pages. One of its standout features is the ability to focus testing on a specific portion of a page. By limiting the scope to just a particular node in the DOM (Document Object Model), you can concentrate on the part of the page you're currently working on, saving time by filtering out irrelevant results.

This toolkit is invaluable for testing accessibility before going live, as it allows you to work on a local version of the page and see how it performs. The ARC Toolkit integrates seamlessly with Chrome’s Developer Tools, enabling you to quickly locate specific code and experiment with how to correct any issues within your environment.

The ARC Toolkit supports a wide range of accessibility standards, including WCAG 2.0, WCAG 2.1, WCAG 2.2, EN 301 549, and Section 508. It is designed to complement both automated and manual testing processes, simplifying repetitive tasks and helping you interactively explore accessibility features and problems.

When launched from Developer Tools, the ARC Toolkit provides a panel with a set of tests that display results both in the panel and directly on the page. You can toggle each test on or off to isolate specific types of issues, making it easier to pinpoint and address problems. Additionally, issues can be selected and examined directly in the Elements panel. This tool also provides “Alerts” and “Best Practices” that may or may not reflect actual accessibility issues. It is worth noting that this tool does produce some false positives, particularly related to element nesting or layering.

The toolkit runs entirely locally within Chrome, meaning it can evaluate any page you can browse to, including those in iframes. For pages still in development and not yet live, you can enable the option to "Allow access to file URLs" to evaluate them.

As the ARC Toolkit is actively used by the TPGi team, it benefits from frequent updates, ensuring that the rules and features are continually refined and developed to meet the latest accessibility standards.

Our team leverages the ARC Toolkit in several key ways to ensure that web pages meet accessibility standards:

1. Text Spacing Verification: We use the ARC Toolkit to check whether pages maintain correct functionality and readability when text spacing adjustments are applied. This is crucial for users who require increased spacing for better legibility.
2. Reflow Testing at High Zoom Levels: The toolkit allows us to quickly set a page to 400% zoom and the correct viewport width, which is ideal for checking how well the page content reflows without losing functionality or readability. This is especially important for users who rely on magnification.
3. Element Identification: The ARC Toolkit visually marks various elements on the page, such as Headings, Landmarks, Tables, and more. This helps our team ensure that these elements are correctly structured and accessible to assistive technologies.

Tab Order and Focus Visibility: We utilize the toolkit to identify the tab order of interactive elements on the page. This is essential for ensuring that users who navigate via keyboard can do so in a logical and intuitive order. The ARC Toolkit also helps us check for visible focus indicators, which are crucial for users relying on keyboard navigation.

Axe DevTools helps us to identify and address potential issues throughout the development cycle. Here’s how we effectively use this tool:

1. Accessibility Checker for Developers, Testers, and Designers in Chrome: Axe DevTools is a tool for quick accessibility checks within the Chrome browser. Its integration into our workflow allows us to spot and fix issues during the development process.
2. Automated Testing with a Focus on Accuracy: We utilize axe DevTools for automated testing, which efficiently identifies many common accessibility issues with a single click. While the tool aims to reduce false positives, they can still occur. We use these results as a starting point and follow up with manual checks to ensure accuracy and address the issues effectively.
3. Managing False Positives: Although axe DevTools is designed to minimize false positives, they are not entirely avoidable. This requires our team to sometimes verify flagged issues manually to confirm their validity. Understanding this, we integrate axe DevTools as part of a broader strategy, using it alongside manual testing and other tools to ensure comprehensive accessibility coverage.
4. Intelligent Guided Testing™ (IGT) Available for Extra Support: While we do not currently use the Intelligent Guided Testing™ (IGT) feature, it’s a valuable paid option for teams that need more guidance and support in identifying and understanding complex accessibility issues. IGT offers a more hands-on approach, using a guided question-and-answer format to help teams catch issues that might not be detectable through automated testing alone. This feature can be particularly beneficial for teams looking to enhance their testing process without requiring deep accessibility expertise.
5. Component-Level Testing: We frequently utilize component-level testing in axe DevTools Pro to focus on specific sections of a page, which is especially useful for large or complex websites. This targeted approach allows us to address relevant issues without being distracted by unrelated elements.
6. Collaboration and Reporting: Collaboration is key in our development process, and axe DevTools makes it easy to share findings across our team. We generate customized URLs with detailed issue descriptions, streamlining communication and tracking through our issue management tools. This ensures that everyone on the team is aligned and working toward building accessible, inclusive user experiences.

In summary, while axe DevTools is a powerful and essential part of our accessibility toolkit, we recognize its limitations and use it in conjunction with other methods to deliver thoroughly accessible websites. The available advanced features like IGT offer additional support for teams that require more guidance.

Stylus is a versatile browser extension that allows you to apply custom CSS styles to webpages. It's particularly useful for enforcing text spacing requirements when other tools, like ARC Toolkit, do not fully support these functions.

ANDI (Accessible Name & Description Inspector) is a powerful, free accessibility testing tool that is easy to use and integrates well into the web development workflow. To install ANDI, you simply need to bookmark or drag the ANDI link to your browser's bookmarks bar, enabling quick access without any complex setup.

ANDI offers a range of features to help developers identify and address accessibility issues. Key features include visual highlights of focusable and interactive elements, detailed information on element accessibility, and modules for specific accessibility areas like links, tables, and hidden content. The tool is designed to work alongside screen readers and other developer tools, providing alerts categorized by severity to streamline the remediation process.

ANDI’s interface is user-friendly, with advanced settings and hotkeys to make navigation efficient. Although it doesn’t support dynamic content or Shadow DOM, ANDI’s ability to provide real-time feedback and detailed analysis makes it an invaluable resource for ensuring web content meets accessibility standards.

• ANDI excels in visualizing table header associations, ensuring that each header is correctly linked to its corresponding cells. This feature is crucial for users relying on screen readers, as it guarantees accurate context when navigating tables.
• Additionally, ANDI's ARIA (Accessible Rich Internet Applications) checking tool is highly effective. The hovering option allows for field-by-field inspection, minimizing false positives and making it easier to verify ARIA attributes' accuracy. This functionality simplifies the process of ensuring compliance with accessibility standards.

The Focus Style Bookmarklet applies highly visible keyboard focus indicators, aiding in manual keyboard testing, especially on pages with poor or nonexistent focus styles. This tool is invaluable for tracking focus on websites that lack sufficient focus indicators

The H123 Bookmarklet creates a quick list of all headings on a page, allowing you to assess the structure and ensure that heading levels are used appropriately. This is a critical tool for screen reader navigation.

The Target Size Bookmarklet helps identify overlapping elements by their tap size, ensuring compliance with WCAG 2.2 guidelines. This is crucial for touch devices where tap targets must be adequately spaced.

This tool assists in designing buttons that are both visually appealing and accessible. By adjusting color contrast for button text and backgrounds, the Accessible Contrast Button Generator ensures that buttons are not only compliant with WCAG standards but also easy to distinguish and interact with, which is vital for users with visual impairments.

The Eightshapes Contrast Grid allows us to test and compare multiple foreground and background color combinations simultaneously. This tool is especially useful for ensuring that all text elements across a website maintain the necessary contrast levels, regardless of the color scheme being used. It is also effective in assessing the contrast of non-text elements, such as icons and graphical buttons, which are crucial for indicating interactivity or the state of an element.

The TPGI Colour Contrast Analyzer is an essential tool for checking the contrast ratio between foreground and background colors. It helps ensure that text is readable across different backgrounds and meets the WCAG (Web Content Accessibility Guidelines) standards. This tool is particularly useful for verifying the contrast of text over solid backgrounds but can also be applied to more complex scenarios with careful consideration.

JAWS (Job Access With Speech) is a premier screen reader for the Windows operating system, developed by Freedom Scientific. It has long been the industry standard for screen readers, offering a rich set of features that make it essential for users who are blind or visually impaired. However, it is also one of the more expensive screen readers available, which impacts its usage across different regions.

Key Aspects of JAWS in Our Testing Process

1. Industry-Leading Features: JAWS provides comprehensive support for a wide range of applications, including Microsoft Office, web browsers like Chrome and Firefox, and various email clients. This extensive compatibility allows us to thoroughly test the accessibility of our digital products across different environments, ensuring that users who rely on JAWS can interact with content effectively.
2. Keyboard-Driven Interaction: Because JAWS is designed for users who cannot see the screen, it relies entirely on keyboard commands for navigation and interaction. This feature is central to our testing process, as it enables us to evaluate how well products support keyboard-only navigation, which is critical for users who cannot use a mouse. We focus on areas such as focus management, keyboard shortcuts, and the accessibility of complex interfaces.
3. Regional Usage Variability: According to the most recent WebAIM screen reader survey, JAWS is most commonly used in North America and Australia, but its usage is lower in regions like Europe, Africa, the Middle East, and Asia, where NVDA is more prevalent. This discrepancy is likely influenced by the cost of JAWS, which can be prohibitive for many users in regions with lower adoption rates. Understanding these regional differences informs our testing strategies and helps us ensure global accessibility.
4. Free Testing Version: While JAWS is expensive, Freedom Scientific offers a free version of the software specifically for testing purposes. This version allows 40-minute sessions requiring a computer reboot to use the software. Although the time limit may seem restrictive, it is usually sufficient to complete specific testing tasks. This free version is a valuable resource for our team, allowing us to perform detailed accessibility checks without incurring the full cost of the software.

Comprehensive Testing Approach: Due to the high cost of JAWS and its varied usage across different regions, we complement our JAWS testing with other screen readers, such as NVDA. This strategy ensures that our products are accessible to users who may not have access to JAWS due to financial constraints. By using a combination of screen readers, we can deliver a more inclusive and accessible digital experience for all users.

NVDA (NonVisual Desktop Access) is a vital tool in our accessibility testing process, offering robust features that ensure our digital products are accessible to users who rely on screen readers. Here’s how we effectively use NVDA in our workflow:

1. Cross-Platform Accessibility Testing: NVDA is an essential part of our cross-platform testing strategy. While we use other tools like VoiceOver for macOS, NVDA is our primary screen reader for testing on Windows. This approach allows us to detect and address accessibility issues that may appear differently across operating systems, ensuring broad accessibility across platforms commonly used in various environments.
2. Web and Application Testing: We rely on NVDA to test the accessibility of web applications, especially in widely used browsers such as Chrome and Firefox. NVDA helps us verify that web content, including forms, navigation menus, and dynamic elements, is accessible and easy to navigate for screen reader users. This is crucial for ensuring that all interactive and informational elements are properly conveyed to users who are visually impaired.
3. Support for Third-Party Applications: NVDA is compatible with a wide range of third-party applications, including office suites, email clients, and chat programs. Our team uses NVDA to test these applications to ensure that users can access and interact with them effectively. This testing is particularly important for enterprise environments where consistent accessibility across various software tools is necessary.
4. Braille Display Integration: NVDA’s support for refreshable braille displays is another key feature. We test the compatibility of digital products with braille displays to ensure that users who rely on braille can access the content effectively. NVDA’s integration with the LibLouis braille translator allows us to verify both uncontracted and contracted braille output, making it an essential tool for comprehensive accessibility testing.
5. Portable Testing Environment: One of NVDA’s strengths is its ability to run from a USB flash drive or other portable media without installation. This feature is particularly useful for testing across different machines and environments, allowing us to ensure consistent accessibility without needing to install the software on each device.
6. Compatibility with Accessibility APIs: NVDA supports a variety of accessibility APIs, including Microsoft Active Accessibility (MSAA), UI Automation (UIA), and IAccessible2. This broad compatibility enables us to test custom and third-party applications that rely on these APIs, ensuring that they are accessible to all users, regardless of the technology they use.

Real-World User Simulation: By using NVDA in its default configuration, we replicate the experience of real-world users. This approach helps us identify potential accessibility barriers that might not be evident during automated testing or when using customized settings, ensuring that our testing reflects the true user experience.

VoiceOver is a critical tool in our accessibility testing process, particularly for evaluating native mobile applications. Given that many apps are now built using frameworks that allow a single code base to deploy on both iOS and Android, VoiceOver testing is essential because each operating system exposes different accessibility gaps. Here’s how we leverage VoiceOver across various platforms:

1. Cross-Platform Testing with VoiceOver: VoiceOver on macOS, iOS, and iPadOS can behave differently due to the unique ways each operating system handles accessibility features. For example, navigation gestures and the interaction model might vary slightly between macOS and iOS devices. It’s important for our team to test across these platforms to ensure that accessibility is consistently implemented, especially for apps that are intended to work seamlessly across multiple devices.
2. Native Mobile Application Evaluation: VoiceOver is particularly valuable when evaluating native mobile applications. With the rise of cross-platform development frameworks, many applications are built using a single code base for both iOS and Android. However, despite this unified approach, accessibility gaps can still emerge differently on each platform. Testing with VoiceOver on iOS and iPadOS allows us to identify and address these platform-specific issues, ensuring that the application is accessible regardless of the operating system.
3. Web and App Navigation Testing: Our team uses VoiceOver, best paired with the Safari browser for web testing, to thoroughly test navigation within web pages and mobile apps. VoiceOver’s rotor, gestures, and quick navigation tools allow us to assess how easily users can move through content, activate buttons, and understand the hierarchy of information. By not altering VoiceOver’s default settings, we ensure that our testing reflects the experience of the majority of users, who typically use the screen reader as configured out-of-the-box.
4. Dynamic Content and Announcements: VoiceOver is also essential for verifying how dynamic content updates and announcements are handled. Whether on a webpage or within a mobile app, we ensure that changes in content are announced correctly and that users relying on VoiceOver receive timely and accurate feedback.

‍

Browser developer tools offer a range of functions that are invaluable for manual accessibility testing. Some of the key tools we use include:

• Source Panel: We use the Source Panel to pause scripts and inspect loading components. This is particularly useful for identifying issues with content that loads dynamically, ensuring that all elements are properly rendered and accessible when they appear on the page.
• Elements > Accessibility Panel: The Accessibility Panel within the Elements tab allows us to inspect the accessibility tree for proper structure. We use this tool to verify that elements are correctly represented in the accessibility tree and that screen readers can accurately convey the page's content.

Focus Tracking Using Console Commands: One of the advanced techniques we employ during manual testing is focus tracking using console commands. By adding a live expression in the console, such as document.activeElement, we can dynamically monitor where the focus is on the page which is particularly helpful when focus is not visible. The Console tool in browser developer tools allows us to execute these commands and monitor focus in real-time, helping us identify potential focus management issues. This ensures that the user experience is smooth and intuitive for keyboard users, especially during complex interactions and dynamic content changes.

Keyboard testing is essential for ensuring that all interactive elements on a page are accessible without the use of a mouse. This is particularly important for users who rely on keyboard navigation, such as those using screen readers or those with motor impairments. During keyboard testing, we:

• Check Focus Order: We ensure that the focus moves logically through interactive elements, following a natural and intuitive order. This prevents confusion and frustration for users who rely on keyboard navigation.
• Verify Keyboard Accessibility: We test all interactive elements, such as links, buttons, and forms, to ensure they can be accessed and activated using the keyboard alone. This includes checking for proper focus indicators to visually show which element is currently selected.

Assess Focus Management: We evaluate how well focus is managed during dynamic content updates, ensuring that focus remains in the correct place or is appropriately redirected as the page content changes.

Manual code reviews are critical for identifying potential accessibility issues that might not be flagged by automated tools. Our code review process includes:

• Structural Analysis: We inspect the HTML and CSS to ensure that the page structure is semantic and follows best practices. This includes checking that headings are correctly nested, ARIA roles and attributes are used appropriately, and that interactive elements are marked up correctly for assistive technologies.

ARIA and Semantics: We verify that ARIA roles, states, and properties are used correctly to enhance the accessibility of custom components. We also ensure that the use of ARIA does not override or conflict with native HTML semantics.

Purpose: This command is useful for monitoring when a webpage has fully loaded. It helps you determine if any change in keyboard focus or other behaviors are the result of the page reloading, which is crucial for debugging focus management and ensuring a smooth user experience.

Usage:

window.addEventListener("load", (event) => {

  console.log("page is fully loaded");

});

Tip: Implement this command in your testing to log a message when the page has completely loaded. By correlating this log with any unexpected focus shifts or content changes, you can determine whether these are caused by the page reload itself or by other scripts and interactions on the page. This insight is particularly valuable for ensuring that focus remains consistent and predictable during page load events, which is essential for users relying on keyboard navigation.

Purpose: These commands allow you to simulate dynamic content changes over time, which is crucial for testing whether screen readers correctly announce these updates. By introducing delays, you can mimic real-world scenarios where content is updated asynchronously, ensuring that all users receive timely and accurate feedback.

Usage:

setTimeout(function() {

    document.querySelector('selector').textContent = 'New content';

}, 3000);

Tip: This example simulates a content update after 3 seconds. You can adjust the timing and content as needed to test different scenarios. This is particularly useful for validating that screen readers announce changes to dynamic content, such as live updates or AJAX-driven changes.

Purpose: This command helps you identify all focusable elements on a page, ensuring they are properly accessible through keyboard navigation. It's an effective way to audit the interactive elements on your site and verify that they can be navigated using only the keyboard.

Usage:

document.querySelectorAll('a[href], button, input, select, textarea, [tabindex]');

Tip: This command lists all focusable elements on the page, which you can then inspect for accessibility issues. For example, you can check if any elements are missing tabindex attributes or if there are elements that should not be focusable but are, helping you refine the accessibility of your site’s navigation.

Purpose: This command is essential for monitoring which element is currently in focus on a webpage. It's particularly useful for verifying that keyboard navigation and focus management are functioning correctly. By tracking the active element, you can ensure that users who rely on keyboard navigation or screen readers are able to interact with your content as intended.

Usage:

console.log(document.activeElement);

Tip: You can use this command in conjunction with a live expression in the console to continuously monitor focus changes as you navigate through the page using the keyboard. This real-time feedback is invaluable for identifying focus-related issues, such as unexpected focus shifts or missing focus indicators.

Browser zoom is a built-in feature in all major web browsers that allows users to increase or decrease the size of web content. It is an essential tool for users with low vision who may need to enlarge text and images to make them easier to read. Our team tests websites at various zoom levels, typically up to 400%, to ensure that content reflows properly, images scale without loss of clarity, and interactive elements remain accessible and functional. Testing browser zoom helps us identify potential issues with layout, content overlap, and readability that might not be apparent at the default zoom level.

System or device zoom is a feature available in operating systems like Windows and macOS, as well as on mobile devices, that allows users to magnify the entire screen. This is particularly useful for users who need consistent magnification across all applications and not just within a web browser. We test products using system/device zoom to ensure that all aspects of the user interface—whether within an app or the operating system itself—remain accessible. This includes checking that text remains readable, buttons are easily clickable, and that the overall user experience is not compromised at higher magnification levels.

ZoomText Magnifier/Reader is a specialized tool designed specifically for users with low vision. It provides a fully integrated magnification and screen reading experience, offering flexible magnification levels up to 60x. This tool not only magnifies the screen but also enhances contrast, echoes typing, and reads out documents, web pages, and emails. Our team uses ZoomText to simulate the experience of users who rely on high levels of magnification and screen reading. We test how content is displayed and read out by ZoomText, ensuring that it remains clear, accessible, and easy to navigate even at extreme magnification levels.

ZoomText allows for a wide range of magnification options, from 1x to 36x or even up to 60x on certain versions of Windows. The software supports fractional zoom levels (e.g., 1.25x, 1.5x) and custom zoom level configurations, enabling users to fine-tune their experience based on their specific needs. Our testing with ZoomText helps us ensure that users who need this level of magnification can interact with our products effectively.