🔍 ICJIA Institute to Innovate (I2I) v2 2024 - Accessibility Audit Report

Accessibility audit report for the Illinois Criminal Justice Information Authority's Institute to Innovate (I2I) capacity-building program website.

Generated: 1/16/2026, 5:51:47 PM

Environment: Development (http://localhost:8000)

axe-core version: 4.11.1

Pages tested: 27

Viewports tested: desktop, tablet, mobile

Themes tested: light, dark

Repo access: This repository is private. For source-level details, contact the ICJIA web development team.

Total Violations

Total Passes

6486

Pages Passing

Skip Links

162/162

📋 All Tested Pages

URL	Viewport	Theme	Passes	Incomplete	Total Tests	Status	Skip Link
/	desktop	light	40	2	42	✅ Pass	✅ OK
/	desktop	dark	40	2	42	✅ Pass	✅ OK
/	tablet	light	40	2	42	✅ Pass	✅ OK
/	tablet	dark	40	2	42	✅ Pass	✅ OK
/	mobile	light	40	2	42	✅ Pass	✅ OK
/	mobile	dark	40	2	42	✅ Pass	✅ OK
/privacy	desktop	light	40	2	42	✅ Pass	✅ OK
/privacy	desktop	dark	40	2	42	✅ Pass	✅ OK
/privacy	tablet	light	40	2	42	✅ Pass	✅ OK
/privacy	tablet	dark	40	2	42	✅ Pass	✅ OK
/privacy	mobile	light	40	2	42	✅ Pass	✅ OK
/privacy	mobile	dark	40	2	42	✅ Pass	✅ OK
/training-and-technical-assistance	desktop	light	41	2	43	✅ Pass	✅ OK
/training-and-technical-assistance	desktop	dark	41	2	43	✅ Pass	✅ OK
/training-and-technical-assistance	tablet	light	41	2	43	✅ Pass	✅ OK
/training-and-technical-assistance	tablet	dark	41	2	43	✅ Pass	✅ OK
/training-and-technical-assistance	mobile	light	42	2	44	✅ Pass	✅ OK
/training-and-technical-assistance	mobile	dark	42	2	44	✅ Pass	✅ OK
/grant-opportunities	desktop	light	39	2	41	✅ Pass	✅ OK
/grant-opportunities	desktop	dark	39	2	41	✅ Pass	✅ OK
/grant-opportunities	tablet	light	39	2	41	✅ Pass	✅ OK
/grant-opportunities	tablet	dark	39	2	41	✅ Pass	✅ OK
/grant-opportunities	mobile	light	40	2	42	✅ Pass	✅ OK
/grant-opportunities	mobile	dark	40	2	42	✅ Pass	✅ OK
/biographies/clair-daney	desktop	light	38	2	40	✅ Pass	✅ OK
/biographies/clair-daney	desktop	dark	38	2	40	✅ Pass	✅ OK
/biographies/clair-daney	tablet	light	38	2	40	✅ Pass	✅ OK
/biographies/clair-daney	tablet	dark	38	2	40	✅ Pass	✅ OK
/biographies/clair-daney	mobile	light	39	2	41	✅ Pass	✅ OK
/biographies/clair-daney	mobile	dark	39	2	41	✅ Pass	✅ OK
/biographies/cornelius-davis	desktop	light	38	2	40	✅ Pass	✅ OK
/biographies/cornelius-davis	desktop	dark	38	2	40	✅ Pass	✅ OK
/biographies/cornelius-davis	tablet	light	38	2	40	✅ Pass	✅ OK
/biographies/cornelius-davis	tablet	dark	38	2	40	✅ Pass	✅ OK
/biographies/cornelius-davis	mobile	light	39	2	41	✅ Pass	✅ OK
/biographies/cornelius-davis	mobile	dark	39	2	41	✅ Pass	✅ OK
/biographies/katherine-l-staten	desktop	light	39	2	41	✅ Pass	✅ OK
/biographies/katherine-l-staten	desktop	dark	39	2	41	✅ Pass	✅ OK
/biographies/katherine-l-staten	tablet	light	39	2	41	✅ Pass	✅ OK
/biographies/katherine-l-staten	tablet	dark	39	2	41	✅ Pass	✅ OK
/biographies/katherine-l-staten	mobile	light	40	2	42	✅ Pass	✅ OK
/biographies/katherine-l-staten	mobile	dark	40	2	42	✅ Pass	✅ OK
/biographies/courtney-wade	desktop	light	38	2	40	✅ Pass	✅ OK
/biographies/courtney-wade	desktop	dark	38	2	40	✅ Pass	✅ OK
/biographies/courtney-wade	tablet	light	38	2	40	✅ Pass	✅ OK
/biographies/courtney-wade	tablet	dark	38	2	40	✅ Pass	✅ OK
/biographies/courtney-wade	mobile	light	39	2	41	✅ Pass	✅ OK
/biographies/courtney-wade	mobile	dark	39	2	41	✅ Pass	✅ OK
/biographies/andrea-gatewood	desktop	light	38	2	40	✅ Pass	✅ OK
/biographies/andrea-gatewood	desktop	dark	38	2	40	✅ Pass	✅ OK
/biographies/andrea-gatewood	tablet	light	38	2	40	✅ Pass	✅ OK
/biographies/andrea-gatewood	tablet	dark	38	2	40	✅ Pass	✅ OK
/biographies/andrea-gatewood	mobile	light	39	2	41	✅ Pass	✅ OK
/biographies/andrea-gatewood	mobile	dark	39	2	41	✅ Pass	✅ OK
/biographies/brandon-hilton	desktop	light	39	2	41	✅ Pass	✅ OK
/biographies/brandon-hilton	desktop	dark	39	2	41	✅ Pass	✅ OK
/biographies/brandon-hilton	tablet	light	39	2	41	✅ Pass	✅ OK
/biographies/brandon-hilton	tablet	dark	39	2	41	✅ Pass	✅ OK
/biographies/brandon-hilton	mobile	light	39	2	41	✅ Pass	✅ OK
/biographies/brandon-hilton	mobile	dark	39	2	41	✅ Pass	✅ OK
/biographies/chandrea-chaiyarat	desktop	light	39	2	41	✅ Pass	✅ OK
/biographies/chandrea-chaiyarat	desktop	dark	39	2	41	✅ Pass	✅ OK
/biographies/chandrea-chaiyarat	tablet	light	40	2	42	✅ Pass	✅ OK
/biographies/chandrea-chaiyarat	tablet	dark	40	2	42	✅ Pass	✅ OK
/biographies/chandrea-chaiyarat	mobile	light	40	2	42	✅ Pass	✅ OK
/biographies/chandrea-chaiyarat	mobile	dark	40	2	42	✅ Pass	✅ OK
/biographies/shyam-limachia	desktop	light	38	2	40	✅ Pass	✅ OK
/biographies/shyam-limachia	desktop	dark	38	2	40	✅ Pass	✅ OK
/biographies/shyam-limachia	tablet	light	39	2	41	✅ Pass	✅ OK
/biographies/shyam-limachia	tablet	dark	39	2	41	✅ Pass	✅ OK
/biographies/shyam-limachia	mobile	light	39	2	41	✅ Pass	✅ OK
/biographies/shyam-limachia	mobile	dark	39	2	41	✅ Pass	✅ OK
/biographies/aaliyah-gaston	desktop	light	38	2	40	✅ Pass	✅ OK
/biographies/aaliyah-gaston	desktop	dark	38	2	40	✅ Pass	✅ OK
/biographies/aaliyah-gaston	tablet	light	39	2	41	✅ Pass	✅ OK
/biographies/aaliyah-gaston	tablet	dark	39	2	41	✅ Pass	✅ OK
/biographies/aaliyah-gaston	mobile	light	39	2	41	✅ Pass	✅ OK
/biographies/aaliyah-gaston	mobile	dark	39	2	41	✅ Pass	✅ OK
/biographies/jim-blissitt-iii	desktop	light	39	2	41	✅ Pass	✅ OK
/biographies/jim-blissitt-iii	desktop	dark	39	2	41	✅ Pass	✅ OK
/biographies/jim-blissitt-iii	tablet	light	40	2	42	✅ Pass	✅ OK
/biographies/jim-blissitt-iii	tablet	dark	40	2	42	✅ Pass	✅ OK
/biographies/jim-blissitt-iii	mobile	light	40	2	42	✅ Pass	✅ OK
/biographies/jim-blissitt-iii	mobile	dark	40	2	42	✅ Pass	✅ OK
/biographies/demetri-alexakos	desktop	light	39	2	41	✅ Pass	✅ OK
/biographies/demetri-alexakos	desktop	dark	39	2	41	✅ Pass	✅ OK
/biographies/demetri-alexakos	tablet	light	40	2	42	✅ Pass	✅ OK
/biographies/demetri-alexakos	tablet	dark	40	2	42	✅ Pass	✅ OK
/biographies/demetri-alexakos	mobile	light	40	2	42	✅ Pass	✅ OK
/biographies/demetri-alexakos	mobile	dark	40	2	42	✅ Pass	✅ OK
/biographies/dr-tasha-williams	desktop	light	40	2	42	✅ Pass	✅ OK
/biographies/dr-tasha-williams	desktop	dark	40	2	42	✅ Pass	✅ OK
/biographies/dr-tasha-williams	tablet	light	40	2	42	✅ Pass	✅ OK
/biographies/dr-tasha-williams	tablet	dark	40	2	42	✅ Pass	✅ OK
/biographies/dr-tasha-williams	mobile	light	40	2	42	✅ Pass	✅ OK
/biographies/dr-tasha-williams	mobile	dark	40	2	42	✅ Pass	✅ OK
/graduations/2023-i2i-graduation	desktop	light	43	2	45	✅ Pass	✅ OK
/graduations/2023-i2i-graduation	desktop	dark	43	2	45	✅ Pass	✅ OK
/graduations/2023-i2i-graduation	tablet	light	43	2	45	✅ Pass	✅ OK
/graduations/2023-i2i-graduation	tablet	dark	43	2	45	✅ Pass	✅ OK
/graduations/2023-i2i-graduation	mobile	light	43	2	45	✅ Pass	✅ OK
/graduations/2023-i2i-graduation	mobile	dark	43	2	45	✅ Pass	✅ OK
/announcements/i2i-team-growth	desktop	light	40	2	42	✅ Pass	✅ OK
/announcements/i2i-team-growth	desktop	dark	40	2	42	✅ Pass	✅ OK
/announcements/i2i-team-growth	tablet	light	40	2	42	✅ Pass	✅ OK
/announcements/i2i-team-growth	tablet	dark	40	2	42	✅ Pass	✅ OK
/announcements/i2i-team-growth	mobile	light	40	2	42	✅ Pass	✅ OK
/announcements/i2i-team-growth	mobile	dark	40	2	42	✅ Pass	✅ OK
/graduations	desktop	light	41	2	43	✅ Pass	✅ OK
/graduations	desktop	dark	41	2	43	✅ Pass	✅ OK
/graduations	tablet	light	41	2	43	✅ Pass	✅ OK
/graduations	tablet	dark	41	2	43	✅ Pass	✅ OK
/graduations	mobile	light	41	2	43	✅ Pass	✅ OK
/graduations	mobile	dark	41	2	43	✅ Pass	✅ OK
/program-overview	desktop	light	43	2	45	✅ Pass	✅ OK
/program-overview	desktop	dark	43	2	45	✅ Pass	✅ OK
/program-overview	tablet	light	43	2	45	✅ Pass	✅ OK
/program-overview	tablet	dark	43	2	45	✅ Pass	✅ OK
/program-overview	mobile	light	43	2	45	✅ Pass	✅ OK
/program-overview	mobile	dark	43	2	45	✅ Pass	✅ OK
/search	desktop	light	43	2	45	✅ Pass	✅ OK
/search	desktop	dark	43	2	45	✅ Pass	✅ OK
/search	tablet	light	43	2	45	✅ Pass	✅ OK
/search	tablet	dark	43	2	45	✅ Pass	✅ OK
/search	mobile	light	44	2	46	✅ Pass	✅ OK
/search	mobile	dark	44	2	46	✅ Pass	✅ OK
/translate	desktop	light	39	2	41	✅ Pass	✅ OK
/translate	desktop	dark	39	2	41	✅ Pass	✅ OK
/translate	tablet	light	40	2	42	✅ Pass	✅ OK
/translate	tablet	dark	40	2	42	✅ Pass	✅ OK
/translate	mobile	light	40	2	42	✅ Pass	✅ OK
/translate	mobile	dark	40	2	42	✅ Pass	✅ OK
/contact	desktop	light	41	2	43	✅ Pass	✅ OK
/contact	desktop	dark	41	2	43	✅ Pass	✅ OK
/contact	tablet	light	41	2	43	✅ Pass	✅ OK
/contact	tablet	dark	41	2	43	✅ Pass	✅ OK
/contact	mobile	light	41	2	43	✅ Pass	✅ OK
/contact	mobile	dark	41	2	43	✅ Pass	✅ OK
/biographies	desktop	light	40	2	42	✅ Pass	✅ OK
/biographies	desktop	dark	40	2	42	✅ Pass	✅ OK
/biographies	tablet	light	40	2	42	✅ Pass	✅ OK
/biographies	tablet	dark	40	2	42	✅ Pass	✅ OK
/biographies	mobile	light	40	2	42	✅ Pass	✅ OK
/biographies	mobile	dark	40	2	42	✅ Pass	✅ OK
/announcements	desktop	light	39	2	41	✅ Pass	✅ OK
/announcements	desktop	dark	39	2	41	✅ Pass	✅ OK
/announcements	tablet	light	39	2	41	✅ Pass	✅ OK
/announcements	tablet	dark	39	2	41	✅ Pass	✅ OK
/announcements	mobile	light	40	2	42	✅ Pass	✅ OK
/announcements	mobile	dark	40	2	42	✅ Pass	✅ OK
/resources	desktop	light	41	2	43	✅ Pass	✅ OK
/resources	desktop	dark	41	2	43	✅ Pass	✅ OK
/resources	tablet	light	41	2	43	✅ Pass	✅ OK
/resources	tablet	dark	41	2	43	✅ Pass	✅ OK
/resources	mobile	light	41	2	43	✅ Pass	✅ OK
/resources	mobile	dark	41	2	43	✅ Pass	✅ OK
/cohorts	desktop	light	41	2	43	✅ Pass	✅ OK
/cohorts	desktop	dark	41	2	43	✅ Pass	✅ OK
/cohorts	tablet	light	41	2	43	✅ Pass	✅ OK
/cohorts	tablet	dark	41	2	43	✅ Pass	✅ OK
/cohorts	mobile	light	41	2	43	✅ Pass	✅ OK
/cohorts	mobile	dark	41	2	43	✅ Pass	✅ OK

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 (16)

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
skip-link: Ensures skip links exist and point to valid targets (WCAG 2.1 Level A, SC 2.4.1 - Bypass Blocks)
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 40). 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 162/162 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:

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.
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.
Visual Check: When the skip link receives focus, it should be clearly visible with a focus indicator (outline, background color, etc.).

Additional Resources

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.2.1 and Vuetify 3.