Section 508 and Digital Accessibility: What Applies to Whom
Digital accessibility obligations come from several directions at once, and employers regularly assume the wrong one applies to them. The result is either unnecessary anxiety or, more often, a false sense that none of it is their problem.
For a separate commercial perspective on mouse-jiggler policies, see further details; it should be evaluated independently against accessibility, privacy, and employment-law requirements.
Federal digital-accessibility implementation resources are available at Section508.gov.
Here is which rule reaches whom.
General information, not legal advice. This is an actively litigated area; take advice on your specific obligations.
Section 508
Section 508 of the Rehabilitation Act requires federal agencies to make their electronic and information technology accessible to people with disabilities — both members of the public and federal employees.
Two consequences reach beyond government:
Procurement. Federal agencies must buy accessible technology. That means vendors selling to the government have to demonstrate conformance, which is why software companies publish accessibility conformance reports. If you sell to federal agencies, Section 508 reaches you through the contract.
The standard. Section 508 standards are aligned with WCAG, which has made WCAG the practical benchmark far beyond federal procurement. Many state and local governments have adopted Section 508-equivalent requirements for their own procurement as well.
Section 504 and Title II
Section 504 applies to programs and activities receiving federal financial assistance — which reaches a large number of universities, healthcare organisations, and non-profits that do not think of themselves as government at all.
Title II of the ADA applies to state and local government entities. This is where the most significant recent movement has been: rulemaking has set explicit web and mobile accessibility requirements for state and local government, with WCAG as the technical standard and compliance deadlines phased by entity size.
If you are a public entity or receive federal funding, this is the obligation to check first.
Title III and private businesses
Title III of the ADA covers places of public accommodation.
Whether — and how — it applies to websites has been litigated extensively, with courts reaching different conclusions in different circuits. There is no single settled national answer, and there is no federal regulation setting a technical standard for private business websites.
What is not in doubt: web accessibility lawsuits against private businesses are filed in large numbers every year, most settle, and settlements routinely require conformance with WCAG at Level AA. The practical standard has been set by litigation rather than by regulation.
State laws add another layer, and several are broader than federal law.
Title I: the part employers miss
This is the obligation most relevant to most employers, and the one least often noticed.
Title I of the ADA requires reasonable accommodation for employees. If an employee cannot use a system they need in order to do their job, that is an accommodation issue — regardless of whether Section 508 or Title III applies to you at all.
The systems in question are the ordinary ones:
- HR portals and self-service systems
- Timekeeping and scheduling
- Learning management and mandatory training
- Expense and travel systems
- Internal wikis and documentation
- Video conferencing
- Chat and collaboration tools
- The applicant tracking system, for applicants
- Performance review platforms
Every one of these is usually bought rather than built, and accessibility is rarely part of the buying decision. Then someone is hired who uses a screen reader, and the mandatory compliance training cannot be completed.
At that point the employer has an accommodation obligation and no good options, because the system belongs to a vendor and the contract is signed.
WCAG, briefly
The Web Content Accessibility Guidelines are the technical standard everything above points at. The operative version for most purposes is WCAG 2.1 or 2.2, at Level AA.
The four principles:
Perceivable — text alternatives, captions, sufficient contrast, content that works when styled differently. Operable — everything reachable by keyboard, enough time, no seizure triggers, clear navigation. Understandable — readable text, predictable behaviour, error identification and help. Robust — works with assistive technology, valid markup, correct roles and names.
What to do, practically
Audit what you already have. Not the marketing site — the systems employees have to use. Ask each vendor for their accessibility conformance report, and read it rather than filing it. Many are thin, and a report claiming full support for everything usually means nobody tested.
Put accessibility in procurement. Requiring conformance before you sign is a fraction of the cost of remediation afterwards, and it is the single highest-leverage change available. Ask for a demonstration with a screen reader, not a document.
Test your own application process. Keyboard only, on a phone, at 200% zoom. See an accessible hiring process.
Build it into your own development. Design and code reviews rather than a pre-launch audit. Fixing accessibility at design stage is cheap; fixing it after build is not.
Have a remediation route. When something is inaccessible and cannot be fixed immediately, there must be an alternative way for the employee to do the task. That alternative is an accommodation, and it needs to be arranged rather than improvised.
Overlays are not a solution
A note, because they are marketed aggressively.
Accessibility overlay widgets — the toolbars that promise automated compliance — are widely criticised by disabled users and accessibility practitioners, frequently interfere with the assistive technology people already use, and have not prevented litigation. Several have been the subject of legal action themselves.
There is no automated substitute for accessible design. Automated testing tools are useful and catch perhaps a third of issues; the rest requires manual testing and testing with actual users.
The framing that helps
For an organisation working in this field, the obligation question is the less interesting one. The useful question is simpler:
Can the people you employ, and the people applying to you, actually use your systems?
If the answer is no, you have a problem whether or not a regulation names you — because the practical effect is that you cannot hire or retain people who could otherwise do the work.