Title IINew Rule
Need to KnowKey Requirements
What is Title II?
Title II of the Americans with Disabilities Act (ADA) prohibits discrimination based on disability by state and local governments. This federal civil rights law requires state and local governments to provide individuals with disabilities effective communication, reasonable modifications, and an equal opportunity to participate in or benefit from their services, programs, and activities.
The Department of Justice’s new final rule, published on April 24, 2024, updates Title II regulations with specific requirements for ensuring that web content (including documents) and mobile applications are accessible to people with disabilities.
As administrative staff, you create and distribute documents, correspondence, and forms that fall under these requirements.
Required Standard
All documents, mobile applications, media, and web content must follow WCAG 2.1, Level AA guidelines, unless a clear exception applies. Documents secretaries create, including letters, forms, notices, and agendas, must follow this standard when posted or distributed digitally.
Compliance Timeline
| State / Government Size | Compliance Deadline |
|---|---|
| 50,000 or more people | April 24, 2026 |
| 0 to 49,999 people | April 26, 2027 |
| Special district governments | April 26, 2027 |
Conforming Alternate Version Disclaimer
State and local governments should not maintain an inaccessible main web page alongside a separate accessible version of the same content. People with disabilities must receive equal access to content on the same page, not a segregated alternative.
Need to KnowRule Exceptions
The following categories of content are not required to conform to WCAG 2.1, Level AA under the new Title II Final Rule. All conditions listed must be met for an exception to apply.
New Final Rule Exceptions
Archived Web Content
All conditions must apply:
- Created before the compliance date
- Kept only for reference, research, or recordkeeping
- Kept in an area designated for archived content
- Not changed since being archived
A permission slip created before the compliance date may qualify, but any updated or reissued version does not.
Preexisting Conventional Electronic Documents
Both conditions must apply:
- In a word processing, presentation, PDF, or spreadsheet format
- Made available before the compliance date
Registration forms, letter templates, and intake packets reused or redistributed after the compliance date are not exempt, only the original pre-deadline version qualifies.
Third Party Content (Non-Contractual)
- Posted by the entity itself or someone acting on the entity’s behalf
- Subject to a contract that gives the entity oversight or control over accessibility
Individual Documents with Password Protection
All conditions must apply:
- In a word processing, presentation, PDF, or spreadsheet format
- About a specific individual, their property, or their account
- Password-protected or otherwise secured
Individualized student notices distributed digitally may qualify, confirm with your compliance contact before relying on this exception.
Preexisting Social Media Posts
Who BenefitsFrom Accessibility?
Digital accessibility is not only a fundamental right for people with disabilities, it benefits a wide variety of users and organizations.
| Group | How Does Accessibility Benefit Them? | Example |
|---|---|---|
| People with Disabilities | Eliminates barriers that hinder access to information and communication. | A person with cerebral palsy who cannot speak clearly benefits from AAC systems, speech synthesizers, or text-to-speech applications. |
| Older Adults | Facilitates digital navigation when visual, hearing, or motor difficulties arise with age. | Larger font sizes and high contrast settings improve reading on mobile devices. |
| People with Temporary Disabilities | Helps those with injuries or momentary health conditions. | A person with a cast arm can use voice commands instead of typing. |
| Varying Digital Literacy | Offers more intuitive and accessible navigation options. | A site with clear instructions and pictograms helps users with low literacy navigate easily. |
| Low-Bandwidth Environments | Improves the experience for users with slow connections or older devices. | An optimized site loads quickly in areas with poor internet coverage. |
| Users Who Prefer Accessible Features | Some users without disabilities prefer accessible options for convenience. | Turning on captions while watching a video in a noisy environment. |
| Companies & Organizations | Ensures compliance with accessibility regulations, improves image, and reaches more customers. | An accessible e-commerce site allows more people to shop online. |
| Government Institutions | Ensures compliance with regulations and inclusion in public services. | An accessible services portal ensures all citizens can use it regardless of ability. |
| Educational Institutions | Facilitates learning for students with different needs and abilities. | An online course with audio, video, and text options improves comprehension for all. |
| Content Creators & Developers | Digital products reach more audiences and improve the overall user experience. | A content creator who adds image descriptions makes their content more inclusive. |
AccessibilityQuick Resources
Materials
AccessibilityTools for Secretaries
Free tools to check your work before distributing documents, forms, notices, and emails. Step-by-step guides for the first two tools are in pages SEC-A11Y-015 and SEC-A11Y-012.
Checking Documents You Create
- Microsoft Word Accessibility Checker: Review tab → Check Accessibility. Checks: missing alt text, heading structure, contrast, vague link text, table headers. Free & built in.
- Grackle Docs (Google Workspace add-on): Extensions → Grackle Docs → Open. Checks: headings, alt text, tables, reading order, PDF/UA compliance. Install once from Google Workspace Marketplace. Free.
Checking Color Contrast
- WebAIM Contrast Checker at webaim.org/resources/contrastchecker; enter hex codes and it reports WCAG AA pass/fail instantly. Free, browser-based.
- Colour Contrast Analyser: free desktop app (Windows/Mac); eyedropper to sample any color on screen. Tests against WCAG 2.1.
- GLTHS colors: Blue #1F3886 on white passes AA (8.2:1) | Gold #FFCA38 on white fails (1.6:1) | Dark Gold #B8860B on white passes AA (4.6:1)
Plain Language Check
- Hemingway App at hemingwayapp.com; free, browser-based. Flags complex sentences, passive voice, and reading grade level. Aim for Grade 8 or below for parent-facing text.
Checking PDFs Before Distribution
- Adobe Acrobat Pro: All Tools → Prepare for Accessibility → Check for accessibility.
- Without Acrobat Pro: export from Word using File → Save As → PDF → Options → “Document structure tags for accessibility” + “Best for electronic distribution.” This preserves Word’s heading structure in the PDF.
Checking Web Pages
- WAVE: wave.webaim.org or browser extension (Chrome/Firefox/Edge). Free. Flags missing alt text, heading errors, contrast failures, and empty links on any live page.
Word Keyboard Shortcuts
- Heading 1: Ctrl+Alt+1 | Heading 2: Ctrl+Alt+2 | Insert link: Ctrl+K | Alt text: right-click image → Edit Alt Text
Daily Workflow
- Draft in Word or Google Docs using heading styles and alt text from the start
- Run Word Accessibility Checker or Grackle Docs: fix all errors before distributing
- Paste parent-facing text into Hemingway App: aim for Grade 8 or below
- Export to PDF using “Best for electronic distribution” + “Document structure tags”
- Send: include live text in email body, not image-only attachments
DocumentAccessibility
Ensure your Word documents are readable and navigable for all students and colleagues, including those using screen readers and other assistive technologies.
Document Setup
- Always Avoid Scanning Documents: All documents must be original digital versions that can be edited
- Always Start from Accessible Templates: Use GLTHS provided Word templates to more easily create accessible documents
Structure & Navigation
- Proper Heading Structure: Use built-in heading styles (Heading 1, 2, 3) instead of just bold text to create logical document navigation
- Lists and Bullets: Use Word's built-in list formatting rather than manual bullets or numbers
- Reading Order: Organize content logically from top to bottom, left to right
- Table Structure: Add proper column headers and use "Repeat Header Rows" for multi-page tables
Text & Readability
- Readable Fonts: Choose clear, sans-serif fonts (Arial, Calibri, Lato) at minimum 12pt size for body text
- Color and Contrast: Don't rely on color alone to convey information; ensure 4.5:1 contrast ratio minimum
- Write in Plain Language: Use short sentences and paragraphs, an active voice, and avoid technical jargon, abbreviations, and acronyms
Images & Links
- Alternative Text (Alt Text) for Images: Add descriptive alt text to all images, charts, and graphics through the Alt Text menu
- Inline Images: All images must be placed in-line and cannot be "tight" to text
- Meaningful Link Text: Write descriptive hyperlinks ("GLTHS Course Catalog") instead of generic text ("click here")
Emails & NewslettersAccessibility
Accessible email works best when it is clear and simple. Use live text, descriptive buttons, and a reading order that still works when images are blocked or layouts collapse on mobile.
Do This First
- Lead with the message: Subject line, preheader, and opening heading must clearly explain what the email is about and what action is needed
- Build with resilient content: Use live HTML text for the key message, descriptive buttons, and alt text for every meaningful image
- Test fallback states: Check the email with blocked images, dark mode, mobile width, keyboard navigation, and screen reader reading order
Content Checks
- Use plain language and short paragraphs so readers can skim quickly
- Make every button and link clearly state its destination or action
- Repeat essential text that appears inside hero images as real HTML text
Layout Checks
- Prefer a single-column structure with a logical source order
- Use tables only when email-client support requires them, and keep them simple
- Avoid hover-only interactions or content that depends on animation to make sense
Testing Checks
- Confirm body text reaches 4.5:1 contrast and controls meet 3:1 non-text contrast
- Check that linked images still make sense when images are off
- Review any auto-generated caption or transcript links if video is promoted in the message
Common Problems to Avoid
- Sending an image-only flyer as the email body
- Using complex multi-column layouts that collapse into a confusing mobile order
- Relying on color alone to show urgency, status, or discount information
- Writing vague calls to action such as "read more" or "learn more" without context
Forms & IntakeAccessibility
Creating accessible intake documents (permission slips, registration forms, sign-in sheets) ensures every family can read, understand, and complete them regardless of disability or language background.
Form Structure
- Use a logical reading order: title → instructions → fields in the order a person would naturally complete them
- Group related fields with visible section labels (“Student Information,” “Parent/Guardian Information”)
- Place labels directly above or to the left of their field, never below or to the right only
- Do not place instructions after the signature line
Labels & Field Identification
- Every blank line or box must have a label, never rely on position alone to identify a field
- Mark required fields with both an asterisk and the word “required”, not color alone
- Include a legend at the top: “* = Required”
- For yes/no and multiple-choice items, print the question and each option as readable text, not image-only checkboxes
Fillable vs. Print Forms
- Digital fillable PDFs: use proper form fields with labels, tab order set in document order, and a visible focus indicator
- Print forms: at least 0.35″ line spacing, sufficient field width, checkboxes at least 0.25″ square
- When offering both formats, ensure content and field structure are identical between versions
- Label each version clearly: “Printable Version” vs. “Fill Online”
Forms & IntakeAccessibility
Covers plain language in instructions, accessible alternatives, and common problems to avoid in forms and intake documents.
Plain Language in Instructions
- Write instructions at a 6th–8th grade reading level (check free at hemingwayapp.com)
- Use short sentences (under 20 words) and active voice
- Define any acronym or program name on first use
- Read instructions aloud, if a phrase is awkward to say, rewrite it
Providing Alternatives
- Always offer a paper option when a digital form is primary
- Note on the form how to request a large-print version or translation
- Include a staff contact name or phone number for accessibility accommodation requests
- When distributing by email, include the form as an attachment and an accessible plain-text summary in the email body
Common Problems to Avoid
- Distributing a scanned photocopy as the primary form, scans cannot be read by screen readers
- Two-column layout where reading order jumps unpredictably between columns
- Labels as placeholder text only inside the field (disappears when the user starts typing)
- Instructions in font smaller than 11pt
Graph & ChartAccessibility
Ensure your graphs & charts are legible and navigable for all students and colleagues, including those using screen readers and other assistive technologies.
Chart Design
- Avoid Chart Clutter: Avoid 3D charts, shadows, too many gridlines, backgrounds, and intense colors
-
Color and Contrast: Don't rely on color alone to convey information; ensure 4.5:1 contrast ratio minimum. All parts of charts must have high color contrast to background and each other (bar colors, pie colors, gridlines, labels, legends)
- Patterns, borders, and separating chart elements can help distinguish sections
- Use Common Chart Types: Stick with bar, pie, and line charts when possible
Data Presentation
- Round Numbers When Possible: Reduce mental load by decreasing the amount of decimal points and numbers provided visually
- Sort Data Logically: Make sure bar charts are sorted high to low or vice-versa
- Provide Tables for Complex Charts/Graphs: When charts or graphs cannot be simplified enough, provide an accessible table of the same data
Labeling
- Alternative Text (Alt Text) for Images: Add descriptive alt text to all charts and graphs
- Captions: Add easy to understand captions to all charts and graphs through the References menu
Grackle DocsGoogle Docs Accessibility Checker
Grackle Docs is a free Google Workspace add-on that checks Google Docs, Slides, and Sheets for accessibility issues and helps you fix them before exporting or sharing.
Running a Check
- Extensions → Grackle Docs → Open → click Run Check
- Issues appear organized by category (Headings, Images, Tables, Links, Color, Language). Click any item to jump to that location in the document.
Fix: Missing Heading Structure
- Click the flagged paragraph → open the Styles dropdown in the toolbar (shows “Normal text”) → select Heading 1, Heading 2, or Heading 3 as appropriate
Fix: Image Without Alt Text
- Click the flagged image → right-click → Alt text → type a description in the Description field (leave Title blank). Or use Grackle’s built-in alt text field in the panel.
Fix: Uninformative Link Text
- Select the link → right-click → Edit link → change the display text to something descriptive (e.g., “2026 School Calendar” instead of “click here”)
Fix: Table Without Header Row
- Click in the first table row → right-click → Table properties → under Row, check Pin header rows. For accessible PDF export, use Grackle’s table tagging wizard in the panel.
Exporting an Accessible PDF
- Google’s default PDF export does not include full accessibility tags. After resolving all issues, click Export PDF in the Grackle panel to generate a tagged, PDF/UA-compliant file.
- Without Grackle export: File → Download → PDF Document creates a basic PDF; use Word’s PDF export for better results.
Grackle Slides (Google Slides)
- Extensions → Grackle Slides → Open. Checks for unique titles in title placeholders (not text boxes), alt text on images, reading order, and slide contrast.
Common Problems to Avoid
- Running the check but not fixing errors before exporting to PDF or sharing the link
Meeting MinutesAccessibility
Accessible agendas and minutes help all participants, including those using screen readers or reviewing documents remotely, find information quickly and understand the structure of the meeting record.
Agenda Structure
- Use Heading 1 for the meeting title (e.g., “School Council Meeting - May 6, 2026”)
- Use Heading 2 for each agenda section (e.g., “1. Call to Order,” “2. Approval of Minutes”)
- Use Heading 3 for sub-items when needed, do not skip heading levels
- Do not use bold body text as a substitute for heading styles, it creates no navigable structure
- Include a plain-text header block: meeting name, date, time, location, and presiding officer
Minutes Structure
- Follow the same heading hierarchy as the agenda, minutes should mirror the agenda order
- Use a simple table for action items: columns for Item, Responsible Party, and Due Date
- Do not merge table cells or nest tables; keep one header row with clear column labels
- Enable “Repeat Header Rows” in Word table properties for tables that may span a page break
Text & Readability
- Write minutes in plain language at a professional but accessible reading level
- Avoid passive voice that obscures who made a motion or who is responsible for an action
- Spell out names, roles, and program names on first use in each document
- Use numbered lists for sequential steps and bulleted lists for non-sequential items
Meeting MinutesAccessibility
Covers distributing minutes accessibly, archiving best practices, and common problems to avoid when preparing accessible meeting records.
Distributing Minutes Accessibly
- Run the Word Accessibility Checker before converting to PDF or sending
- When saving as PDF: File → Save As → PDF, check “Best for electronic distribution” and “Document structure tags for accessibility”
- Send minutes as an editable .docx attachment or an accessible PDF, not a scanned printout
- Include a plain-text summary of major decisions in the email body when distributing by email
Archiving Considerations
- Use a consistent filename:
YYYY-MM-DD-Meeting-Name-Minutes.docx - Retain the editable source file (.docx) alongside the PDF in the archive folder
- Do not store minutes only as scanned images, scans are inaccessible to screen readers
- When archiving pre-compliance-date documents, note in the folder that pre-deadline files may not be fully remediated
Common Problems to Avoid
- Scanned or photographed handwritten notes as the official record
- Distributing a document with tracked changes or comments still visible
- Sending minutes as an image-only email or embedded screenshot
- Omitting the responsible party from recorded action items
Microsoft WordAccessibility Checker
The Accessibility Checker is built into Word, PowerPoint, and Excel. Run it before sending or printing to catch the most common errors automatically.
Opening the Checker
- Windows / Mac / Microsoft 365 (browser): Click the Review tab → Check Accessibility. The pane opens on the right and updates as you edit.
- Windows keyboard shortcut: Press Alt, R, AC sequentially (not held together)
Understanding the Results
- Errors (must fix): block access for screen reader users. Example: an image with no alt text.
- Warnings (should fix): may cause difficulty. Example: a link that says “click here.”
- Tips (consider fixing): best-practice suggestions. Example: a table without a caption.
Fix: Missing Alt Text on an Image
- Click the flagged item in the pane → Word highlights the image → right-click → Edit Alt Text
- Type a brief description of what the image shows. For purely decorative images, check Mark as decorative instead.
Fix: Unclear Hyperlink Text (“Click Here,” Raw URL)
- Click the flagged link → right-click → Edit Hyperlink → change the Text to display field to a descriptive phrase (e.g., “2026 School Calendar PDF”)
Fix: Missing Table Header Row
- Click in the table → Table Design tab → check Header Row
- Then right-click table → Table Properties → Row tab → check Repeat as header row at the top of each page
Fix: Low Color Contrast
- Select the flagged text → Home tab → Font Color → choose a darker color. Verify the new combination at webaim.org/resources/contrastchecker (need 4.5:1 for body text).
Exporting an Accessible PDF
- The Accessibility Checker only checks the Word source. For an accessible PDF: File → Save As → PDF → Options (Windows) or More options (Mac)
- Check Document structure tags for accessibility and choose Best for electronic distribution. Word’s heading structure carries into the PDF.
PowerPoint-Specific Notes
- Missing slide title: every slide needs a unique descriptive title in the title placeholder, not a plain text box
- Reading order: View → Reading Order Pane to confirm content reads top-to-bottom as intended
- Duplicate slide title: two identical titles confuse screen reader navigation: the checker will flag this
Community NoticesAccessibility
Letters home, flyers, and community announcements are often the first point of contact families have with the school. Making them accessible ensures every parent can read and act on the information.
Plain Language for a Parent Audience
- Write at a 6th–8th grade reading level, many families read in a second language (check free at hemingwayapp.com)
- Lead with the most important information: what is happening, when, what action is needed
- Use short paragraphs (3–4 sentences max) and bullet points for multi-item information
- Avoid education jargon and acronyms; spell out program names on first use
- Use active voice: “Please return the form by Friday” not “Forms should be returned”
Multilingual Considerations
- Do not use machine translation as the final product for legal or safety-critical notices without human review
- Apply the same accessibility checks to every language version of a document
- Include a contact name and phone number for families who need verbal interpretation
Accessible Flyer Design
- Minimum 12pt body text; 14pt or larger for headers
- Text-to-background contrast: 4.5:1 for body text, 3:1 for large headlines (check at webaim.org/resources/contrastchecker)
- Do not place text over a busy photograph or patterned background
- Use a maximum of two fonts; avoid decorative script fonts for body text
- Clear reading order: headline → date/location → key details → call to action → contact
Community NoticesAccessibility
Covers images and alt text in digital notices, print vs. digital distribution, and common problems to avoid when communicating with families.
Images & Alt Text in Digital Notices
- Every decorative image should be marked as decorative (empty alt text)
- Informational images (maps, event photos, QR codes) must have descriptive alt text
- A QR code must always be accompanied by the full URL in plain text below it
- Do not use an image of text as a headline, use real, styled document text
Print vs. Digital Distribution
- When sending a flyer via email, embed the key information as live text in the email body, do not send only an image attachment
- Paper copies remain the primary accessible alternative for families without reliable internet access
Common Problems to Avoid
- Image-only flyers with no alt text or live text equivalent
- Bright yellow or light-colored text that fails contrast requirements
- Long URLs in paper notices, use short links or QR codes with plain-text backup
- Notices that bury the date, deadline, or contact information at the bottom
PresentationAccessibility
Make your presentations inclusive for all students and colleagues, including those using screen readers, with mobility limitations, or visual impairments.
Before You Start
- Always Start from Accessible Templates: Use GLTHS provided PowerPoint templates to more easily create accessible documents
- Animation Considerations: Limit or avoid flashing animations that could trigger seizures
Slide Structure
- Slide Structure: Use built-in slide layouts and heading styles for proper reading order
- Reading Order: Organize content logically from top to bottom, left to right, and check all slides with the reading order pane
- Title Text: Ensure all slides have a descriptive title
- Lists and Bullets: Use PowerPoint's built-in list formatting rather than manual bullets or numbers
Text & Readability
- Readable Fonts: Choose clear, sans-serif fonts (Arial, Calibri, Lato) at minimum 12pt size for body text
- Color and Contrast: Don't rely on color alone to convey information; ensure 4.5:1 contrast ratio minimum
- Meaningful Link Text: Use descriptive link text instead of "click here" or raw URLs
- Write in Plain Language: Use short sentences and paragraphs, an active voice, and avoid technical jargon, abbreviations, and acronyms
Images & Tables
- Alternative Text (Alt Text) for Images: Add meaningful descriptions for photos, charts, and graphics using PowerPoint's Alt Text feature
- Inline Images: All images must be placed in-line and cannot be "tight" to text
- Table Headers: Properly format data tables with column and row headers
Social MediaAccessibility
Design your social media posts to be accessible to all students, colleagues, and community members, including those who are deaf, hard of hearing, blind, or have other disabilities.
Images & Media
-
Alternative Text (Alt Text) for Images: Write descriptive alternative text for all images posted to social media
- Text within image posts needs to appear in the post content or ALT text if short enough
- Avoid GIFs and Animations: GIFs and animations are often unstoppable and may contain harmful flashing
- Captions: Provide accurate, synchronized captions for all spoken content and important sound effects
Text & Formatting
- Readable Fonts: Choose clear, sans-serif fonts (Arial, Calibri, Lato) at minimum 12pt size for body text
- Color and Contrast: Don't rely on color alone to convey information; ensure 4.5:1 contrast ratio minimum
- Write in Plain Language: Use short sentences and paragraphs, an active voice, and avoid technical jargon, abbreviations, and acronyms
Platform Best Practices
- CamelCase for Hashtags: Use capital letters for each word in hashtags, e.g., #BackToSchool
-
Use Emojis With Care: Avoid large numbers of emojis and try to place them at the end when possible
- Want to learn more about what emojis mean? Check out the emoji dictionary, Emojipedia!
SurveyAccessibility
Build accessible survey content that is perceivable, operable, and understandable for all students, colleagues, and community members, including those using screen readers, keyboard navigation, or other assistive technologies.
User Experience
- Provide Clear Time Estimates: Let users know up front the expected time to complete the survey
- Show Progress Indicators: Always include progress indicators, especially on multi-page surveys
- Offer Paper Versions: When needed, have a paper version available to be printed
Content
- Write in Plain Language: Use short sentences and paragraphs, an active voice, and avoid technical jargon, abbreviations, and acronyms
TableAccessibility
Ensure your tables in Word documents are properly structured and navigable for all students and colleagues, including those using screen readers and other assistive technologies.
Structure
- Always Use Table Headers: Designate the first row as header rows using Word's "Header Row" option in the Table Design tab
- Proper Table Structure: Use Word's Insert Table feature rather than creating tables with tabs or spaces
- Avoid Merged Cells: Avoid merged cells to prevent breaking table layouts
- Simple Table Layout: Avoid complex nested tables; break complex data into multiple simple tables when possible
Headers & Labels
- Clear Column Headers: Write descriptive, concise headers that clearly identify what data each column contains
- Repeat Header Rows: For multi-page tables, enable "Repeat Header Rows" so headers appear on each page
- Table Captions: Add a descriptive caption above the table using Insert Caption to explain the table's purpose
- Table Summary: For complex tables, include a brief description before the table explaining its structure and key findings
Data & Formatting
- Consistent Data Types: Keep data types consistent within each column (all dates, all numbers, all text)
- No Blank Rows or Columns: Don't use empty rows/columns for spacing; use table formatting options instead
- Text Alignment: Left-align text in data cells; only center-align headers when appropriate
Video & MultimediaAccessibility
Make your educational videos, recorded lectures, and multimedia content accessible to all students and colleagues, including those who are deaf, hard of hearing, blind, or have other disabilities.
Audio & Captions
- Audio Descriptions: When informational actions are happening on screen, add narration describing important visual information for viewers who are blind
- Captions: Provide accurate, synchronized captions for all spoken content and important sound effects
- Transcripts: Create full text transcripts that include speaker identification and sound descriptions
- Clear Audio: Record with minimal background noise and clear speech
Visual Safety
- Avoid Flashing Content: No content must flash more than 3 times per second
- Color and Contrast: Don't rely on color alone to convey information; ensure 4.5:1 contrast ratio minimum
Web ContentAccessibility
Build inclusive web content that works for all students, colleagues, and community members, including those using screen readers, keyboard navigation, or other assistive technologies.
Semantic Structure
- Proper Heading Structure: Use built-in heading styles (Heading 1, 2, 3) instead of just bold text to create logical navigation
- Only One H1 Per Page: Only one H1 tag (Heading 1) is allowed per page
- Use Semantic HTML & WAI-ARIA: Use proper HTML elements for their intended purpose (
button,nav,main,section) and add ARIA labels, roles, and descriptions when needed for complex interactive elements - Use Built-In Features: Lists, tables, and headings should all be created using built-in tools or semantic HTML
- Lists and Bullets: Use
<ul>,<ol>, and<dl>for all lists
Navigation & Links
- Keyboard Navigation: Ensure all interactive elements can be accessed using Tab, Enter, and arrow keys
- Reading Order: Organize content logically from top to bottom, left to right
- Meaningful Link Text: Write descriptive hyperlinks ("GLTHS Course Catalog") instead of generic text ("click here")
- Meaningful Page Title: Use descriptive, unique titles for each page, e.g., "Course Syllabus - Automotive Technology"
Content & Readability
- Alternative Text (Alt Text) for Images: Write concise, descriptive alternative text for all images, charts, and graphics
- Readable Fonts: Choose clear, sans-serif fonts (Arial, Calibri, Lato) at minimum 12pt size for body text
- Color and Contrast: Don't rely on color alone to convey information; ensure 4.5:1 contrast ratio minimum
- Write in Plain Language: Use short sentences and paragraphs, an active voice, and avoid technical jargon, abbreviations, and acronyms
Common Mistakes& What to Avoid
The most frequent accessibility errors in school documents, forms, and communications, and how to fix each one.
Scanning Documents
Scans create images. Screen readers see a blank page. This affects scanned permission slips, photographed minutes, and forms re-scanned each year instead of using the original Word file. Fix: Always use the original Word file. If the original is lost, retype it. To spot a scan: open in Acrobat and try to highlight text. If you cannot select any text, it is a scan.
Image-Only Flyers & Notices
Sending a JPG or PNG as the only version of a flyer means screen readers read nothing. This affects event announcements, lunch menus sent as photos, and notices designed only as graphics. Fix: Always include the event name, date, time, location, and action required as live text in the email body alongside any image attachment. Better yet, build the flyer in Word using real text.
“Click Here” & Vague Link Text
Screen readers read links out of context. A list of “click here” or “read more” links is meaningless to someone navigating by links alone. Fix: Describe the destination. “Download the 2026 Permission Slip (PDF)” is clear. In Word: Ctrl+K, change the Text to Display field. In Google Docs: right-click the link, then Edit link.
Color Alone for Information
Red text for “urgent,” green/red for pass/fail; users with color blindness or those printing in grayscale receive no information from color alone. Fix: Pair color with text or a symbol. “Urgent, deadline Friday” in bold communicates without relying on color. Add a word label to any color-coded table cell.
Bold Text Instead of Heading Styles
Ctrl+B creates visual emphasis but no navigable document structure. Screen reader users cannot jump between sections of a document that uses bold for titles instead of heading styles. Fix: Use Heading 1, Heading 2, or Heading 3 from the Styles panel (Word: Home tab; Google Docs: toolbar styles dropdown). Bold is for emphasis within a paragraph only.
Common Mistakes& What to Avoid
Five more frequent accessibility errors found in school documents, forms, and communications, each with a concrete fix.
Placeholder Text as Field Labels
When the only label is the gray placeholder text inside an input field, it disappears the moment the user starts typing. They can no longer see what the field is for. Fix: Place every field label as real text above or to the left of the field box, outside the field itself.
Unreadable Font Sizes & Faces
Body text under 11pt, or decorative/script fonts (Brush Script, Papyrus, Comic Sans) used for informational text, create barriers for readers with low vision or dyslexia. Fix: Minimum 12pt body text in a sans-serif font (Arial, Calibri, Lato). Use decorative fonts only for purely decorative elements, never for instructions, labels, or notices.
Missing Alt Text on Images
Without alt text, screen readers announce only “image” with no description of the logo, chart, or photo in the document. Fix: Right-click any image, then choose Edit Alt Text (Word) or Alt text (Google Docs). Describe what the image shows in one to two sentences. For purely decorative images, check “Mark as decorative” in Word or leave the description blank in Google Docs.
Sending Tracked-Changes Versions
Screen readers read every tracked change marker and comment as document content, creating a wall of confusing text for the reader. Fix: Before distributing, go to the Review tab and choose Accept All (or Reject All). Delete all comments. Save a clean copy before sending.
Inaccessible PDF Export Settings
“Print” quality PDF settings strip heading structure, reading order, and form field labels from the exported file. Fix: File → Save As → PDF → Options (Windows) or More options (Mac). Check “Document structure tags for accessibility” and choose “Best for electronic distribution.”
Resource
Directory
AccessibilityAcronyms
Core Standards & Guidelines
- A11Y: Accessibility (11 letters between A and Y)
- ACR: Accessibility Conformance Report
- ADA: Americans with Disabilities Act
- ARIA: Accessible Rich Internet Applications
- ATAG: Authoring Tool Accessibility Guidelines
- POUR: Perceivable, Operable, Understandable, Robust (WCAG Principles)
- UAAG: User Agent Accessibility Guidelines
- VPAT: Voluntary Product Accessibility Template
- W3C: World Wide Web Consortium
- WAI: Web Accessibility Initiative
- WCAG: Web Content Accessibility Guidelines
Changing to W3C Accessibility Guidelines as of 3.0
Accessibility Specific Media
- AD: Audio Description
- ASL: American Sign Language
- CC: Closed Captions
- SRT: SubRip Subtitle Format
- TTML: Time Text Markup Language
- VTT: Web Video Text Tracks
Assistive Technologies
- AT: Assistive Technologies
- JAWS: Job Access With Speech
- NVDA: Nonvisual Desktop Access
- OCR: Optical Character Recognition
- STT: Speech to Text
- TTS: Text to Speech
Document & Media Formats
- DOCX: Word Document
- EPUB: Electronic Publication
- PDF: Portable Document Format
- PPTX: PowerPoint Document
- RTF: Rich Text Format
Technical & Developmental
- ALT Text: Alternative Text
- ANDI: Accessible Name & Description Inspector
- API: Application Programming Interface
- CSS: Cascading Style Sheets
- DOM: Document Object Model
- GUI: Graphical User Interface
- HTML: Hypertext Markup Language
- UD: Universal Design
- UDL: Universal Design for Learning
- UI: User Interface
- URL: Uniform Resource Locator
- UX: User Experience
AccessibilityGlossary - A
- A11y
- : Numeronym for "accessibility" (A + 11 letters + Y). Typically pronounced "ally," giving the term multiple meanings as it represents both the technical concept and the supportive nature of inclusive design.
- Accessibility
- : The concept of designing physical and virtual spaces and points of contact so that they are usable to all people, with an intentional focus on ensuring usability for people with disabilities. Web accessibility means that websites, tools, and technologies are designed and developed so people with disabilities can perceive, understand, navigate, and interact with them effectively.
- Accessibility Conformance Report (ACR)
- : The final report presented to a client once a full Accessibility Conformance Testing (ACT) has been performed. If you need a legally binding version of the ACR, you would use a version of the Voluntary Product Accessibility Template (VPAT).
- Accessibility Conformance Testing (ACT)
- : Commonly referred to as an accessibility audit. The ACT uses various testing methodologies and tools: primarily automated, manual, and assistive technology (AT) devices.
- Accessibility Object Model (AOM)
- : Often called the Accessibility Tree, this refers to the parts of HTML and ARIA that are understood by assistive technologies.
- Accessibility Tree
- : A subset of the DOM tree that contains accessibility-related information for most HTML elements. It is what assistive technologies use to present and interact with content.
- Accommodation
- : Auxiliary aids and services that are provided upon request in order to facilitate access. Examples include extended time on a test, a sign language interpreter added to an event on request, or a transcript provided on request for a podcast.
- Alternative Text (Alt Text)
- : Text that describes the content and function of an image for people who cannot see it. Every non-text element needs a text equivalent to provide an alternative to the image content.
- Americans with Disabilities Act (ADA)
- : U.S. federal law that prohibits discrimination based on disability and requires accessibility in public accommodations and services.
- API (Application Programming Interface)
- : A set of protocols and tools that define how software components should interact. Accessibility APIs allow assistive technologies to communicate with applications.
- ARIA (Accessible Rich Internet Applications)
- : A specification written by the W3C, defining a set of attributes that you can add to HTML elements to support accessibility. These attributes communicate role, state, and property to assistive technologies via accessibility APIs.
- ASL (American Sign Language)
- : A manual and visual language which uses the hands, arms, and fingers, instead of sound, to communicate words and concepts.
- Assistive Technology (AT)
- : Hardware and software that can be "no-tech" (such as a mouth stick), low-tech (such as a keyboard), or high-tech (such as a screen reader). AT is used to help increase, maintain, or improve the capabilities of performing a task for a person with disabilities.
- ATAG (Authoring Tool Accessibility Guidelines)
- : Guidelines that help make authoring tools themselves accessible and help authors create more accessible content.
- Audio Description (AD)
- : Narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone. Audio descriptions provide information about actions, characters, scene changes, and on-screen text.
- Automated Testing
- : The use of software tools to automatically scan and identify potential accessibility issues in digital content.
AccessibilityGlossary - B through I
- Baseline
- : The set of technologies that content can rely on having support for accessibility features in user agents and assistive technologies.
- Braille
- : A tactile writing system used by people who are visually impaired, consisting of patterns of raised dots.
- Captions (Closed/Open)
- : Words that describe the audio or sound portion of a program or video. Captions include dialogue, identifying who is speaking, and include non-speech information conveyed through sound, including meaningful sound effects. Closed captions can be turned on/off; open captions cannot.
- Cognitive Accessibility
- : Design considerations for people with cognitive disabilities, including clear navigation, simple language, and consistent layout.
- Color Contrast
- : The difference in luminance between text and its background. WCAG requires minimum contrast ratios for accessibility.
- CSS (Cascading Style Sheets)
- : A style sheet language used for describing the presentation of HTML documents, including accessibility features like focus indicators.
- Digital Accessibility
- : The practice of building digital products so that all users, regardless of their disability, have equal access to the content or functionality of the product.
- DOM (Document Object Model)
- : A programming interface for HTML documents that represents the page structure as a tree of objects.
- Dragon NaturallySpeaking
- : Voice recognition software that allows users to control computers and input text using voice commands.
- EPUB (Electronic Publication)
- : A free and open e-book standard that supports accessibility features like reflowable text and alternative formats.
- Extended Audio Description
- : Audio description that pauses the video when necessary to provide longer descriptions of visual content.
- Focus Indicator
- : A visual indicator that shows which element currently has keyboard focus. WCAG 2.2 specifies that focus indicators must not be hidden by overlapping elements.
- Focus Management
- : The programmatic control of where keyboard focus moves, particularly important in dynamic content and single-page applications.
- GUI (Graphical User Interface)
- : The visual interface through which users interact with digital devices and applications.
- Heading Structure
- : A framework of headings that organizes the content of a web page or document like a table of contents. Headings are hierarchical with Heading 1 (H1) representing the main idea in the document and sub-sections marked with H2, H3, etc.
- HTML (Hypertext Markup Language)
- : The standard markup language used to create web pages, which includes many built-in accessibility features.
- IAAP (International Association of Accessibility Professionals)
- : A non-profit membership organization focused on advancing the accessibility profession globally.
- Interactive Element
- : Part of a web page, app, or system that a user can interact with and it "does something." For example, links and buttons are interactive as clicking a link takes you to a new page, and clicking a button does something on the current page.
- ISO 14289
- : International standard that specifies requirements for PDF accessibility.
- ISO 40500
- : The ISO adoption of WCAG 2.0 as an international standard.
AccessibilityGlossary - J through R
- JAWS (Job Access With Speech)
- : A popular screen reader software for Windows that helps blind and visually impaired users access computer content.
- Keyboard Navigation
- : The ability to navigate and interact with digital content using only a keyboard, without requiring a mouse.
- Keyboard Shortcuts
- : Key combinations that provide quick access to functions, which must be implemented carefully to avoid conflicts with assistive technology.
- Live Region
- : An ARIA technique for announcing dynamic content changes to screen readers without moving focus.
- Low Vision
- : Visual impairment that cannot be fully corrected with glasses, contacts, or surgery but still allows for some functional vision.
- Manual Testing
- : Human evaluation of accessibility, including testing with assistive technologies and checking for usability barriers.
- Motor Disabilities
- : Physical impairments that affect movement, including conditions that limit fine motor control or require alternative input methods.
- NVDA (Nonvisual Desktop Access)
- : A free, open-source screen reader for Windows operating systems.
- OCR (Optical Character Recognition)
- : Technology that converts images of text into machine-readable text, often used to make scanned documents accessible.
- Operable
- : One of the four WCAG principles, meaning that user interface components and navigation must be operable by all users.
- PAC (PDF Accessibility Checker)
- : The globally used, free PDF accessibility checker that has been established since 2010.
- PDF (Portable Document Format)
- : A file format that can be made accessible through proper tagging, alternative text, and logical reading order.
- Perceivable
- : One of the four WCAG principles, meaning that information and user interface components must be presentable to users in ways they can perceive.
- POUR
- : Shorthand for Perceivable, Operable, Understandable, and Robust, which are the foundational human-focused principles of WCAG.
- Reflow
- : The ability of content to adapt to different screen sizes and zoom levels without requiring horizontal scrolling.
- Robust
- : One of the four WCAG principles, meaning that content must be robust enough to work with various user agents and assistive technologies.
- RTF (Rich Text Format)
- : A document file format that supports basic accessibility features like heading structure.
AccessibilityGlossary - S through Z
- Screen Reader
- : A high-tech assistive technology that uses synthetic language to read and navigate digital documents for people with low or no vision, cognitive issues, and other disabilities.
- Section 508
- : U.S. federal law requiring federal agencies to make their electronic information accessible to people with disabilities.
- Semantic Markup
- : The use of HTML markup to ensure content is identified by its meaning as opposed to just its appearance. Semantic markup enables screen readers to more accurately and usefully interpret the content of web pages.
- SRT (SubRip Subtitle Format)
- : A simple text-based subtitle file format commonly used for video captions.
- STT (Speech to Text)
- : Technology that converts spoken words into written text, useful for people with hearing impairments or motor disabilities.
- Switch Control
- : Alternative navigation method that allows users to control devices using external switches, often used by people with severe motor impairments.
- TalkBack
- : Android's built-in screen reader that provides spoken, audible, and vibration feedback.
- Title II (of ADA)
- : The section of the Americans with Disabilities Act that prohibits discrimination on the basis of disability by state and local governments, also known as "public entities."
- Transcripts
- : Text versions of audio content that provide access to spoken information for people who are deaf or hard of hearing.
- TTS (Text to Speech)
- : Technology that converts written text into spoken words, used by screen readers and other assistive technologies.
- TTML (Timed Text Markup Language)
- : An XML-based format for creating captions and subtitles for video content.
- UAAG (User Agent Accessibility Guidelines)
- : Guidelines for making browsers, media players, and other user agents accessible.
- Understandable
- : One of the four WCAG principles, meaning that information and user interface operation must be understandable to users.
- Universal Design
- : Design philosophy that aims to create products usable by all people without need for specialized adaptations.
- UX (User Experience)
- : The overall experience a person has when interacting with a product, which should be inclusive and accessible to all users.
- VoiceOver
- : Apple's built-in screen reader for macOS and iOS devices.
- VPAT (Voluntary Product Accessibility Template)
- : A template to draft an Accessibility Conformance Report (ACR). An ACR clearly states which accessibility standards a product or service meets and warns about any "accessibility blockers" they may encounter.
- VTT (Web Video Text Tracks)
- : A format for displaying timed text tracks (such as subtitles or captions) with HTML5 video elements.
- W3C (World Wide Web Consortium)
- : An international community that develops open standards to ensure the long-term growth of the Web.
- WAI (Web Accessibility Initiative)
- : A sub-group of the W3C focused only on digital accessibility.
- WAVE (Web Accessibility Evaluation Tool)
- : A browser plug-in developed by WebAIM and a semi-automated accessibility testing tool. WAVE can help developers, content editors, and other stakeholders identify a range of accessibility issues on a per-page basis.
- WCAG (Web Content Accessibility Guidelines)
- : An international set of accessibility standards developed through the W3C, in cooperation with individuals and organizations. WCAG's goal is to provide a single, shared standard for digital accessibility that meets the needs of individuals, organizations, and governments worldwide.
- WebVTT
- : The Web Video Text Tracks format for captions, text video descriptions, and other metadata that is time-aligned with audio or video content.
- Windows High Contrast Mode
- : A user setting on Windows which enforces the system to display screens in very high contrast, such as white text on black backgrounds, or any theme a user chooses.
- ZoomText
- : Screen magnification software that enlarges text and graphics on computer screens for users with low vision.