Purpose

This standard outlines practical accessibility testing expectations for digital content and applications created or maintained by the university.

Our goal is to ensure that all users, including individuals with disabilities, can access, navigate, and interact with our digital resources effectively.

This standard supports:

  • ADA Title II compliance
  • WCAG 2.1 Level AA conformance
  • Institutional accessibility commitments

Shared Responsibility Model

Accessibility is a shared responsibility.

  • Developers ensure accessible code, components, integrations, and functionality.
  • Content creators and editors ensure accessible text, images, documents, and media.
  • Project managers ensure accessibility is considered throughout the lifecycle.

Accessibility testing should occur:

  • During development
  • Before publishing
  • During redesign or major updates
  • As part of periodic review

Minimum Testing Requirements

All public-facing websites, web applications, and digital content must complete the following baseline checks prior to launch or publication.

Automated Testing (Developers & Site Owners)

Run automated accessibility testing tools (e.g., Axe, WAVE, Lighthouse).

Automated testing should:

  • Identify missing alt text
  • Detect color contrast failures
  • Flag structural issues (headings, labels, ARIA misuse)
  • Surface form and interactive control errors

Note: Automated tools typically detect only 30–40% of WCAG issues. Manual review is still required.

Keyboard Accessibility (Required Manual Test)

Test that all interactive elements can be accessed and operated using only a keyboard.

Verify:

  • Logical tab order
  • Visible focus indicator
  • No keyboard traps
  • All dropdowns, modals, accordions, and menus function via keyboard

Screen Reader Spot Check (Manual Test)

Perform a basic screen reader test (NVDA, JAWS, or VoiceOver).

Check:

  • Page title is meaningful
  • Headings create a logical outline
  • Images have appropriate alternative text
  • Links are descriptive out of context
  • Form fields are properly labeled
  • Error messages are announced

Full expert audits may be required for complex applications.

Content Structure and Readability (Content Creators)

Before publishing:

  • Use proper heading hierarchy (do not skip levels)
  • Avoid using color alone to convey meaning
  • Use descriptive link text (avoid “click here”)
  • Ensure tables include header rows
  • Confirm sufficient color contrast when selecting templates or styles
  • Write in clear, plain language when possible

Multimedia Accessibility

For any published audio or video:

  • Provide accurate captions for video
  • Provide transcripts for audio-only content
  • Ensure media players are keyboard accessible

Document Accessibility

Before uploading PDFs or other documents:

  • Ensure documents are properly tagged
  • Include document title and language metadata
  • Verify reading order
  • Confirm images have alt text
  • Run accessibility checker in source application

When possible, use native web content instead of PDFs.

Testing by Role

Developers Must Verify:

  • Semantic HTML structure
  • Proper ARIA usage (only when necessary)
  • Color contrast meets WCAG AA
  • Responsive reflow at 200% zoom
  • Error identification and suggestion
  • Accessible custom components

Content Creators Must Verify:

  • Accessible headings and structure
  • Accurate alt text
  • Clear link text
  • Accessible documents
  • Captioned media

When to Request Additional Review

Consult the EIRAC when:

  • Launching a new web application
  • Implementing third-party tools
  • Creating complex interactive dashboards
  • Conducting major redesigns
  • Accessibility complaints are received

Continuous Improvement

Accessibility testing is not a one-time event.

We encourage:

  • Ongoing training
  • Peer review
  • Periodic site audits
  • Early integration of accessibility into project planning