How Public Libraries Can Create a More Accessible Website

1. The website must work with keyboard only

All content and functionality must be usable with the Tab, Arrow, and Enter keys. Every link, button, menu, form, and feature must operate without a mouse. Manual testing by an accessibility expert is required to guarantee that the website meets this critical accessibility requirement.
If any part is not keyboard operable, the site fails WCAG 2.1.1 Keyboard, which most assistive technologies rely on, and may violate ADA 35.160 Effective Communication.

2. All keyboard focus must be clearly visible

Every interactive element must show a strong, visible focus indicator during keyboard navigation. Focus must never be hidden, faint or disappear during navigation.
WCAG violations: 2.4.7 Focus Visible, 2.4.13 Focus Appearance

3. Images of text must communicate the full message in ALT text

If an image contains text, the alt text must include all words and meaning shown in the image. The message must be communicated equally to screen reader users (Title II Effective Communication Requirement).
WCAG violations: 1.1.1 Non-text Content, ADA Effective Communication

4. Automatic content must have Play, Pause, or Stop controls

Any content that plays, scrolls, moves, or rotates automatically, such as sliders, videos or GIF images, must include a visible, keyboard-operable Play, Pause, or Stop control.
WCAG violations: 2.2.2 Pause, Stop, Hide, 2.1.1 Keyboard

5. HTML headings must follow proper order

Headings must be used in logical order without skipping levels, such as going from H1 to H4. Proper structure is required for screen reader navigation.
WCAG violations: 1.3.1 Info and Relationships, Failure F43

6. All text must meet color contrast requirements

Text must meet required contrast ratios against its background. Color choices must be tested. Accessibility must be built into the design and code. Overlays are not a valid fix.
WCAG violations: 1.4.3 Contrast Minimum, 1.4.1 Use of Color

7. Search form logic must be accessible

All search fields and filters must appear before the submit button in logical screen reader and keyboard order.
WCAG violations: 1.3.2 Meaningful Sequence, 2.4.3 Focus Order

8. All application forms must be web-based

Any application required for access or participation must be available in an accessible online format. Printable or scanned forms violate ADA Effective Communication.
WCAG violations: 1.3.1, 2.1.1, 4.1.2

9. All public documents must be accessible

Policies, meetings, agendas, and minutes must be properly tagged and readable by screen readers. WCAG applies to documents as well as web pages.
WCAG violations: 1.3.1, 1.3.2, 2.4.6, 4.1.1

10. Required fields must be identified with text

Required fields must contain the word “required”. Color or an asterisk alone is not sufficient.
WCAG violations: 1.4.1 Use of Color, 3.3.2 Labels or Instructions

10. Required fields must be identified with text

Required fields must contain the word “required”. Color or an asterisk alone is not sufficient.
WCAG violations: 1.4.1 Use of Color, 3.3.2 Labels or Instructions

11. All links and form controls must have an accessible name

Every interactive element must have a name that assistive technology can identify.
WCAG violations: 2.4.4 Link Purpose, 4.1.2 Name, Role, Value

12. Elements must not have multiple conflicting accessible names

Do not assign different names through visible text, aria-labels, and alt text on the same element. This causes confusion in screen readers.
WCAG violations: 4.1.2, 2.4.6

13. ARIA must be used correctly and only when necessary

ARIA must follow specification rules and only be used when native HTML cannot achieve the same result. Incorrect ARIA breaks accessibility.
WCAG violations: 4.1.2, 1.3.1, 4.1.1

14. Videos must include audio and captions

Any video that communicates information must include clear audio and accurate captions to meet ADA Effective Communication.
WCAG violations: 1.2.2 Captions, 1.2.3 Audio Description, 1.2.5 Audio Description

15. All pages and third-party tools must be manually tested

Every page and third-party resource must be tested using keyboard-only navigation and screen readers. Automated tools alone are not sufficient.
Common WCAG failures: 2.1.1, 2.4.3, 4.1.2

16. Ask for proof of accessibility testing

Require documentation of real testing and remediation. Accessibility must be verified, not promised.

17. Refrain from using accessibility widgets and overlays

Widgets do not fix code issues and may interfere with assistive technologies. True accessibility must be built into the website.
Common WCAG failures: 2.1.1, 1.3.1, 4.1.2

18. Do not publish a false accessibility statement

Only publish an accessibility statement after receiving a formal written accessibility evaluation confirming WCAG compliance. False claims mislead users and may violate ADA Effective Communication requirements.