Title IINew Rule
“Progress over Perfection”
You Don't HaveTo Be an Expert
Accessibility is a skill you build over time, the same way you develop any other part of your teaching practice. No one expects you to master it overnight, and you are not expected to figure it out alone.
What's Actually Expected of You
- Learn at your own pace: Work through the StepStream module on your own time. It is organized by the types of materials you already create, so you can start with whatever is most relevant to your classes
- Apply what you learn going forward: New and updated materials should follow accessibility standards. You are not expected to go back and remediate every file you have ever created
- Use the tools already available to you: The accessibility checkers built into Word, PowerPoint, and Google Slides are free and already in the software you use every day. Running a check before you post or print is a habit, not a burden
It's Okay to Ask Questions
- Ask your department head or administrator: If you are unsure whether something needs to be accessible or how to handle a specific assignment or handout, that is a reasonable question to bring to your supervisor
- Ask the accessibility team: For questions beyond your immediate classroom work, the GLTHS accessibility team is available at accessibility@gltech.org
- Use the reference pages in this packet: The quick-reference cards cover the most common situations you will run into. Keep this packet handy when creating new materials
Common Worries, Answered
- "I'm not a tech person." The built-in checkers in Word, PowerPoint, and Google Slides do most of the work for you. Your job is to respond to what they flag, not to understand every underlying standard
- "I don't have time for this on top of everything else." Accessibility checks add a few minutes when built into your existing workflow. The habit forms quickly, and the first time is always the longest
- "What if I make a mistake?" A missed alt text or an unlabeled heading is not a disciplinary matter. It is something to fix and move forward from. The expectation is that you try, learn, and improve over time
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 instructional staff, you create and distribute lesson materials, handouts, assignments, and presentations 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. Materials teachers create, including handouts, worksheets, slide decks, and assignments, 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 an arm cast 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 Teachers
Free tools to check your materials before posting or printing. Most are built into software you already use every day.
Checking Documents & Presentations
- Microsoft Word / PowerPoint Accessibility Checker: Review tab → Check Accessibility. Flags missing alt text, heading issues, contrast failures, and vague link text. 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.
- GLTHS colors: Blue #1F3886 on white passes AA (8.2:1) | Gold #FFCA38 on white fails (1.6:1)
Checking Reading Level
- Hemingway App at hemingwayapp.com: free, browser-based. Flags complex sentences, passive voice, and reading grade level. Aim for Grade 8 or below for student-facing text.
- Microsoft Word readability stats: File → Options → Proofing → check “Show readability statistics.” Flesch-Kincaid grade level shows after each spell check.
Checking Captions on Video
- YouTube auto-captions: always review and correct before sharing with students. Go to YouTube Studio → Subtitles → edit the auto-generated transcript.
- Google Meet / Teams: both offer live captions during class. Enable in meeting settings before the session starts.
Keyboard Shortcuts
- Word 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 handouts and slides using heading styles and alt text from the start
- Run Word / PowerPoint Accessibility Checker or Grackle Docs: fix all errors before distributing
- Check any video you share has accurate captions before posting to Google Classroom
- Export to PDF using “Best for electronic distribution” + “Document structure tags”
- Post accessible source files alongside PDFs so students can use assistive technology
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., “Unit 3 Essay Rubric 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).
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
Accessible Assessments& Rubrics
Tests, quizzes, and rubrics are instructional materials subject to the same Title II accessibility requirements as handouts and slide decks. A student using assistive technology must be able to read and navigate your assessments independently.
Print Assessments & Quizzes
- Write clear instructions once per section: Repeating or embedding instructions inside individual questions forces students using screen readers to re-read them on every item
- Do not rely on color alone: Highlighting a correct answer in green or marking an incorrect response in red conveys no information to students who cannot perceive color differences
- Leave adequate whitespace: Cramped layouts are a barrier for students with visual processing difficulties. A minimum 1-inch margin and 1.15 line spacing improves readability for all students
Digital Assessments (Google Forms / Online Quizzes)
- Label every question field: The question text must be a visible label directly above or beside its input, not just placeholder text inside the field. Placeholder text disappears when a student starts typing
- Use descriptive answer choices: Radio button choices labeled only A, B, C, D require students to cross-reference a separate key. Write out the full answer text in each option
- Confirm the submit button has a label: In Google Forms this is automatic; in custom-built quizzes, verify the submit or next button has descriptive text, not just an icon or arrow
Rubrics as Tables
- Mark the header row: In Word, click the table → Table Design tab → check Header Row. In Google Docs, right-click the top row → Table properties → Pin header row
- Keep column titles short and descriptive: Screen readers read the column header before each cell. "Exceeds Standard" is clearer than "4" when read aloud in isolation
- Avoid merged cells: Merged cells break screen reader navigation. If you need grouped columns, use a separate row label instead
Images & Diagrams in Assessments
- All question-relevant images require alt text: If a student must interpret a diagram, map, chart, or photograph to answer the question, the alt text must describe what they need to interpret, not just label the image type
- Decorative images should be marked as such: In Word, right-click → Edit Alt Text → check Mark as decorative. This prevents screen readers from announcing irrelevant images
Reading Level of Instructions
- Assessment directions should be at Grade 8 or below. A student who understands the subject content should not be blocked by unnecessarily complex instructions
- Technical and subject-area vocabulary is expected and not subject to the grade-level target; the plain-language requirement applies to the surrounding instructions, not the academic content
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 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
- 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
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
Google Classroom& LMS Accessibility
Accessibility standards apply to everything you post in Google Classroom or any other learning management system. A student using a screen reader or other assistive technology encounters your posts, attachments, and announcements the same way a printed page reaches a student in class.
Assignment Posts & Announcements
- Write in the description field: Use the text body for instructions, not image-only flyers or screenshots of text. Students using screen readers cannot read images
- Use formatting: Break long posts into short paragraphs. Use bold to highlight key information rather than relying on color or all-caps
- Descriptive titles: Assignment titles should clearly state the task (e.g., "Unit 3 Reflection Essay" not "English Assignment 4")
- Announcements follow the same rules: Treat every announcement like an email. Use live text, not a flyer image, so screen reader users receive the same information as everyone else
Attached Files
- Only attach accessible files: Run the accessibility checker on Word or Google Docs files before attaching. Do not attach scanned PDFs — they cannot be read by screen readers
- Post the source file alongside the PDF: Attaching both the original Word/Docs file and the PDF gives students with assistive technology options for how they access the content
- Name files descriptively: "Unit3-Essay-Rubric.pdf" is better than "rubric-final-v2.pdf" for students navigating a file list
- Check Google Docs sharing settings: A file must be set to "Anyone with the link can view" or shared with the student directly. A permission error is an accessibility barrier
Embedded & Linked Video
- Verify captions before posting: Check that auto-generated YouTube captions are accurate. Edit them in YouTube Studio before sharing the link with students
- Include a transcript or summary: For videos without captions, provide a written summary in the post body or as an attached document
- Link directly to the video: Embed or paste the full URL so students using assistive technology can navigate to it without hunting through surrounding text
Google Classroom& LMS Accessibility
Links & Buttons
- Use descriptive link text: Write "View the Unit 3 Rubric" not "click here" or a bare URL. Screen readers read link text aloud and students navigate by links
- Test every link before posting: Broken links are an accessibility barrier. Verify all links open the intended resource
- Avoid raw URLs as display text: A URL like "https://docs.google.com/document/d/1aBcD..." is read character by character by a screen reader. Always use meaningful link text
Feedback & Comments
- Leave comments as text: Written comments in the assignment return are accessible. Voice memo attachments or images of handwritten notes are not
- Be specific: Feedback like "See page 2" is not useful for a student using a screen reader navigating a long document. Reference headings or section titles instead
- Use the private comment field: Private comments in Google Classroom are fully accessible. They are preferable to emailing a separate document containing feedback
Returning Graded Work
- Summarize feedback in the comment box when returning grades: Students using screen readers may not be able to open annotated attachments or audio files. A text summary in the comment field ensures feedback reaches every student
- Avoid annotating directly on images: Handwritten annotations on a scanned or photographed submission cannot be read by assistive technology. Type your response instead
Before You Post: Quick Check
- Is the assignment title specific enough to stand alone out of context?
- Are all instructions typed in the description field, not embedded in an attached image?
- Have all attached files been checked with an accessibility checker?
- Do all links use descriptive text rather than "click here" or a bare URL?
- If a video is included, have its captions been reviewed for accuracy?
Common Problems to Avoid
- Posting an image of the assignment instructions instead of writing them in the description
- Sharing a scanned PDF without also attaching the original editable file
- Embedding a YouTube video with auto-captions that have not been reviewed or corrected
- Using "click here" or bare URLs as link text in assignment descriptions
- Returning graded work with feedback only in an annotated image or voice memo
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
Plain Language& Reading Level
WCAG 3.1.5 requires that written content be provided at lower secondary reading level or that a simplified alternative be available. For teachers, this applies to the instructions and explanations you write, not to the academic vocabulary you are teaching.
Why Reading Level Matters for Accessibility
- Students with dyslexia benefit from shorter sentences and familiar words. Complex syntax adds cognitive load on top of decoding difficulty
- English language learners may have strong content knowledge but limited familiarity with academic English phrasing in directions
- Students with cognitive disabilities may understand the subject but struggle with multi-clause instructions or abstract directions like "demonstrate your understanding of"
How to Check Reading Level
- Hemingway App at hemingwayapp.com: free, browser-based. Paste your text and it reports the grade level, flags long sentences, and highlights passive voice. Aim for Grade 8 or below
- Microsoft Word readability stats: File → Options → Proofing → check “Show readability statistics.” The Flesch-Kincaid grade level appears after each spell check run
- Google Docs has no built-in readability stats. Use the Hemingway App for Google Docs content
Plain Language Practices
- Use active voice: “Submit your essay to Google Classroom” rather than “Essays should be submitted to Google Classroom”
- Keep sentences under 20 words: Break compound sentences into two. One idea per sentence
- Define terms on first use: When subject vocabulary appears in instructions for the first time, briefly define it or provide context
- Avoid double negatives: “Do not submit without a title page” is harder to parse than “Include a title page with your submission”
- Use numbered steps for sequences: Any multi-step process is clearer as a numbered list than as a paragraph with words like “then,” “next,” and “finally”
What Not to Simplify
- Subject-area vocabulary is not subject to the plain language rule: You are expected to teach students words like “mitosis,” “quadratic,” or “iambic pentameter.” Plain language applies to your instructions, not your content
- Academic rigor is not the same as inaccessible writing: A clearly written assignment with precise academic expectations is both rigorous and accessible
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
- Apply Document Accessibility Standards: Standard document accessibility guidelines apply to surveys as well: use descriptive headings to separate sections, add alt text to any images or graphics in questions, and ensure sufficient color contrast on all text and form elements
- Accessible Links and Buttons: Label all action buttons and links descriptively (e.g., "Submit Survey" rather than "Submit"), and ensure any embedded hyperlinks use meaningful link text rather than bare URLs
TableAccessibility
Ensure your tables in 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.