🔍 Statewide Violence Prevention Plan for Illinois: 2025-2029 - Accessibility Audit Report

Accessibility audit report for the Illinois Violence Prevention Plan website.

📋 All Tested Pages

About axe-core

axe-core is an open-source accessibility testing engine developed by Deque Systems. It is one of the most comprehensive and widely-used tools for automated accessibility testing on the web.

What does axe-core test for?

axe-core performs automated checks against the Web Content Accessibility Guidelines (WCAG) and other accessibility standards. The tests check for:

• Semantic HTML: Proper use of HTML elements, ARIA attributes, and landmarks
• Keyboard Navigation: All interactive elements must be keyboard accessible
• Color Contrast: Text must meet WCAG contrast ratio requirements (4.5:1 for normal text, 3:1 for large text)
• Focus Management: Visible focus indicators and logical tab order
• Form Labels: All form inputs must have associated labels
• Image Alt Text: Images must have appropriate alternative text
• Heading Structure: Proper heading hierarchy (h1 → h2 → h3, etc.)
• Landmark Regions: Proper use of ARIA landmarks (banner, main, navigation, contentinfo, etc.)
• Interactive Elements: Buttons, links, and controls must have accessible names
• Language Attributes: HTML lang attribute must be set

Why is axe-core critical for accessibility?

• Automated Testing: Catches accessibility issues early in development, before manual testing
• Comprehensive Coverage: Tests for 50+ accessibility rules covering WCAG 2.1 Level A and AA standards
• Industry Standard: Used by major organizations and accessibility professionals worldwide
• Continuous Integration: Can be integrated into CI/CD pipelines for automated accessibility checks

Rule Categories in This Audit

This audit includes three categories of accessibility rules:

• WCAG 2.1 Level A & AA Rules: These rules test for compliance with Web Content Accessibility Guidelines 2.1 Level A and AA standards. These are required for legal compliance with ADA Title II, IITAA, and Section 508.
• Best Practice Rules: These rules test for accessibility best practices that are recommended but not explicitly required by WCAG 2.1 AA. They help improve overall accessibility and user experience. Examples include:
  • meta-viewport: Ensures viewport meta tag is present for responsive design
  • frame-title: Ensures iframes have descriptive titles
  • html-xml-lang-mismatch: Checks for consistency between HTML lang and XML lang attributes
• Experimental/Cutting-edge Rules: These are cutting-edge accessibility rules that are still being validated. They may catch issues that standard rules miss, but may also have false positives. Currently enabled: css-orientation-lock, no-autoplay-audio, page-has-heading-one, focus-order-semantics, identical-links-same-purpose, link-in-text-block, hidden-content, label-content-name-mismatch, presentation-role-conflict. Examples include:
  • css-orientation-lock: Checks for orientation lock (WCAG 2.1 SC 1.3.4)
  • focus-order-semantics: Checks focus order matches DOM order
  • no-autoplay-audio: Checks for autoplay audio (WCAG 2.1 SC 1.4.2)
  • page-has-heading-one: Checks for h1 on page

Configured Rules Status

This audit uses a custom rule configuration (AXE_RULE_CONFIG) that allows specific rules to be enabled or disabled via boolean values. This configuration is dynamically read from the audit script.

✅ Enabled Rules (15)

The following rules are currently enabled and will be tested:

• aria-allowed-role: Ensures ARIA roles are used correctly and are allowed for the element
• scrollable-region-focusable: Ensures scrollable regions are keyboard accessible
• landmark-banner-is-top-level: Ensures banner landmarks are at the top level
• landmark-contentinfo-is-top-level: Ensures contentinfo landmarks are at the top level
• landmark-main-is-top-level: Ensures main landmarks are at the top level
• landmark-unique: Ensures landmarks are unique
• css-orientation-lock: Checks for orientation lock (WCAG 2.1 SC 1.3.4)
• no-autoplay-audio: Checks for autoplay audio (WCAG 2.1 SC 1.4.2)
• page-has-heading-one: Ensures page has at least one h1 heading
• focus-order-semantics: Checks focus order matches DOM order
• identical-links-same-purpose: Checks for duplicate links with same purpose
• link-in-text-block: Checks link contrast in text blocks (WCAG 2.1 SC 1.4.1)
• hidden-content: Checks for hidden content that should be visible
• label-content-name-mismatch: Checks if label text matches accessible name
• presentation-role-conflict: Checks for presentation role conflicts

❌ Disabled Rules (1)

The following rules are currently disabled:

• region: Disabled due to known incompatibility with Nuxt/Vue component structure. Vue components dynamically create regions that don't match the expected HTML5 landmark structure.

💡 How to Change Rules: Edit the AXE_RULE_CONFIG constant in audit-accessibility.js (around line 37). Set any rule to true to enable it, or false to disable it. Rules are controlled via simple boolean values and are dynamically reflected in this report.

What Are Skip Links?

Skip links (also called "skip navigation links") are accessibility features that allow keyboard and screen reader users to bypass repetitive navigation content and jump directly to the main content of a webpage. They are typically the first interactive element on a page and appear when focused via keyboard navigation.

Why Are Skip Links Important?

Skip links are critical for accessibility and are required by WCAG 2.1 Level A (Success Criterion 2.4.1 - Bypass Blocks). They provide several key benefits:

• Keyboard Navigation Efficiency: Users who navigate with a keyboard (using Tab, Shift+Tab, and arrow keys) can skip over long navigation menus, headers, and other repetitive content to reach the main content faster. Without skip links, keyboard users must tab through every navigation item before reaching the main content.
• Screen Reader Efficiency: Screen reader users can quickly jump to the main content without having to listen to the entire navigation menu being read aloud on every page. This saves significant time and reduces frustration.
• WCAG Compliance: Skip links are required by WCAG 2.1 Level A (Success Criterion 2.4.1 - Bypass Blocks), which is part of the minimum accessibility standards required for legal compliance with ADA Title II, IITAA, and Section 508.
• Better User Experience: Skip links improve the experience for all users, not just those with disabilities. They make websites more efficient to navigate, especially on pages with extensive navigation menus.

How Skip Links Work

Skip links typically work as follows:

• Hidden by Default: Skip links are usually positioned off-screen using CSS (e.g., position: absolute; top: -100px) so they don't interfere with the visual design when not in use.
• Visible on Focus: When a user presses the Tab key to navigate with the keyboard, the skip link becomes visible and receives focus. It should have clear visual focus indicators (outline, background color, etc.) so users can see it.
• Target Main Content: The skip link's href attribute points to the main content area of the page (typically #main-content or #main). When activated, it scrolls the page and moves keyboard focus to that target element.
• Proper Target Setup: The target element (usually the <main> element or a container with id="main-content") should have tabindex="-1" to allow programmatic focus, ensuring keyboard focus moves to it when the skip link is activated.

Skip Link Implementation Requirements

For a skip link to be properly implemented and pass accessibility audits, it must meet these criteria:

• Presence: A skip link must exist on every page of the website.
• Correct Target: The skip link's href must point to the main content area (typically #main-content).
• Target Exists: The target element (e.g., <main id="main-content">) must exist on the page.
• Keyboard Accessible: The skip link must be keyboard accessible (not have tabindex="-1" that prevents keyboard access).
• Visible on Focus: The skip link must be visible when it receives keyboard focus, with clear visual indicators.
• Target is Focusable: The target element should have tabindex="-1" to allow programmatic focus when the skip link is activated.

Current Skip Link Status

✅ All Skip Links Working: This audit found 84/84 skip links are properly implemented and working correctly across all tested pages and viewports. All skip links meet the requirements for presence, target, keyboard accessibility, and focus visibility.

Testing Skip Links

You can test skip links on this website yourself:

1. Using Keyboard: Press the Tab key when the page loads. The skip link should appear at the top of the page. Press Enter to activate it, and the page should scroll to the main content.
2. Using Screen Reader: If you use a screen reader (like NVDA, JAWS, or VoiceOver), navigate to the beginning of the page. The skip link should be the first interactive element announced.
3. Visual Check: When the skip link receives focus, it should be clearly visible with a focus indicator (outline, background color, etc.).

Additional Resources

• WCAG 2.4.1 - Bypass Blocks (Level A)
• W3C Web Accessibility Tutorials: Skip Links
• WebAIM: Skip Navigation Links

About Testing Environments

What are Development and Production Environments?

In web development, environments refer to different stages of a website or application's lifecycle:

• Development Environment: This is the local testing environment where developers build and test the application. It typically runs on a developer's computer (like localhost:8000) and may contain experimental features, debugging tools, and code that hasn't been finalized.
• Production Environment: This is the live, public-facing version of the website that real users interact with. It's the final, deployed version of the application running on a public server (like https://r3.illinois.gov).

Why is it Important to Indicate the Testing Environment?

Knowing which environment the accessibility audit was run against is crucial for several reasons:

• Accuracy of Results: Development and production environments may have different code, configurations, or content. An audit run against development might catch issues that have already been fixed in production, or miss issues that only exist in production.
• Reproducibility: If someone needs to verify or investigate issues found in the audit, they need to know which environment to check. This ensures they're looking at the same version of the code that was tested.
• Context for Stakeholders: For compliance reports, documentation, or stakeholder reviews, it's essential to know whether the audit represents the live, public-facing site (production) or a work-in-progress version (development).
• Debugging and Fixes: When accessibility issues are identified, developers need to know which environment to fix. Issues found in development can be addressed before deployment, while production issues require immediate attention.
• Compliance Verification: For legal compliance and accessibility standards (like WCAG 2.1 AA, IITAA, or ADA Title II), audits should typically be run against the production environment to verify what users actually experience.

Current Audit Environment

This accessibility audit was run against the Development environment at http://localhost:8000. This represents the local development version of the website. For compliance verification, consider running the audit against the production environment as well.

Accessibility Standards & Compliance

IITAA Accessibility Standards for Illinois

Illinois Information Technology Accessibility (IITAA) standards align with WCAG 2.1 Level AA and Section 508, ensuring Illinois state websites are usable by all residents, including those using assistive technologies.

• IITAA Standards Documentation

WCAG 2.1 Level AA Guidelines

The Web Content Accessibility Guidelines (WCAG) 2.1 Level AA are internationally recognized standards for web accessibility.

• WCAG 2.1 Quick Reference

ADA Title II Requirements

ADA Title II requires state and local governments to ensure services, programs, and activities (including websites) are accessible to people with disabilities.

• ADA Title II Overview

Framework Notes

This site is built using Nuxt 4 and Vuetify 3.