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.

Required Standard

Compliance Timeline

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.

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

Communicate It Out

• Share the StepStream module with your team directly: stepstream.dev. A brief mention in a team meeting or a short email is enough to signal that this is a real expectation, not optional background reading
• Set a soft deadline for staff to work through their role-specific module. Framing it as part of normal professional responsibilities helps staff prioritize it over other tasks
• Reference it in context: when reviewing documents, notices, or forms before they go out, mention accessibility as part of your feedback loop

Support Your Staff

• Give them time: building accessible documents takes a little longer at first. Acknowledging that expectation up front reduces the friction of adoption
• Be receptive to concerns: if a staff member flags that a workflow or template is inaccessible, treat it as useful information, not pushback
• Elevate barriers you cannot resolve locally: if staff report that a tool, platform, or existing template cannot meet accessibility standards, escalate that to the district accessibility contact rather than leaving it unaddressed

Questions Staff May Bring to You

• "Is this really required?": Yes. Title II of the ADA requires accessible communications for all public entities. GLTHS is obligated to comply by federal law
• "What do I do with existing documents?": New and updated documents should meet standards going forward. Remediation of a large archive is a separate planning effort - direct those questions to the district accessibility contact

Who to Contact

• For policy or compliance questions, reach out to the GLTHS accessibility team directly at accessibility@gltech.org

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")

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

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

What Counts as a Barrier

• Document not readable by screen reader: Scanned image PDFs, files with no heading structure, or Word docs without alt text
• Video with no captions: Auto-captions alone do not satisfy accessibility requirements if they are inaccurate
• Form that cannot be completed by keyboard: Unlabeled fields, no tab order, or required fields with no accessible label
• Web page or portal failing contrast or navigation: Content on the school website or any linked district-managed platform
• Event or meeting with no accommodation provided: Missing captioning, ASL interpretation, or large-print materials when requested

Who to Contact

• Primary route: Forward all reports to the GLTHS Accessibility Coordinator at accessibility@gltech.org
• Copy your department head on the initial acknowledgment
• Web or portal issue: Also notify the IT or web team directly so the fix can be tracked in their queue

What to Document

• Date and time the report was received
• Name and contact information of the person who reported it
• Specific file name, URL, or location of the barrier
• Description of the barrier and what assistive technology was in use, if known
• Interim accessible alternative provided while fix is in progress

Response Timeline

• Within 2 business days: Acknowledge receipt to the reporter and provide an interim alternative if the fix will take time
• Within 10 business days: Resolve the barrier or escalate with a written explanation to the district-level accessibility contact
• At resolution: Confirm closure with the original reporter in writing

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

Planning: Before You Procure

• State accessibility requirements in the scope, bid language, and contract terms before any vendor review
• Include accessibility for software, websites, learning platforms, documents, hardware, and digital curriculum
• Identify assistive technology compatibility questions early; match scope to real user tasks including forms, alerts, navigation, media, and account access
• Request vendors explain WCAG 2.1 AA support and describe their accessibility duties before committing

Vendor Review

• Obtain a current VPAT or Accessibility Conformance Report (ACR) and ask follow-up questions; reject unsubstantiated "accessible" claims without proof
• Ask which WCAG 2.1 AA criteria the product meets/does not meet and identify all known gaps with remediation timelines and ownership
• Demo must cover keyboard-only use, visible focus, captions, alt text, and basic screen reader compatibility

Decision & Follow-Up

• Tie approval, launch, and fix ownership to measurable, written acceptance criteria
• Maintain written records of questions, responses, and all fix commitments
• Coordinate unresolved issues with leadership and accessibility contacts before signing
• Treat accessibility findings as part of product fit, not optional extras

Common Problems to Avoid

• Purchasing without requesting accessibility evidence
• Accepting incomplete or outdated conformance reports
• Deferring accessibility review to post-implementation
• Skipping real-task demos for key workflows

Warranty of Compliance

Title II Requirements

Documentation & Testing

Remediation

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!

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

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

The Difference

• Translation changes the language of content so a different audience can understand the words
• Accessibility ensures anyone, including people using screen readers, magnification, or keyboard-only navigation, can read and use the content regardless of language
• A perfectly translated Spanish document can still fail accessibility if it is a scanned image, uses poor contrast, or lacks heading structure

The Right Approach

• Translate the editable source file: give the translator the Word document or Google Doc, not a printed copy or PDF to scan
• Run accessibility checks on the translated file: after translation, open the translated Word doc and run the Accessibility Checker before exporting to PDF
• Export to PDF from the translated source file, not from a printed-and-scanned copy of it

When Using a Vendor or Translator

• Specify the deliverable format upfront: the translated file must be returned as an editable Word document or Google Doc
• Do not accept a scanned copy or image-only PDF as the final translation; if received, send it back and request the editable source
• Keep the editable source in both languages so future updates can be made to both versions without starting over

Quick Accessibility Check for Any Document

• Open the PDF and try to highlight and copy text; if you cannot select text, it is a scanned image and is not accessible
• Open the Word doc and run: Review tab → Check Accessibility; fix all errors before distributing in either language

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

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