Monthly Archives: December 2024
When Accessibility Issues in Google Apps Require External Solutions
- Complex Navigation or Interaction Challenges:
- Google apps generally follow WCAG standards, but certain complex workflows (e.g., navigating large spreadsheets or documents with multiple interactive elements) may not fully support screen readers or keyboard-only navigation.
- Example: Managing extensive pivot tables in Google Sheets may not be fully screen-reader-friendly, requiring a switch to Microsoft Excel or a tool like JAWS for better accessibility.
- Non-Editable Content Embedded in Google Docs or Slides:
- If you embed non-accessible elements such as images without alt text, charts, or external media with no captions, these cannot always be fully fixed inside Google apps.
- Solution: Use external software like Adobe Acrobat Pro to enhance accessibility in exported PDFs or a dedicated media editor to caption videos.
- Lack of Advanced Semantic Structuring:
- Google Docs supports headings, but for advanced semantic markup (e.g., ARIA roles or custom landmarks), its capabilities are limited. If you need to ensure accessibility for complex documents, moving to Microsoft Word or HTML editors with ARIA support is necessary.
- Inadequate Support for Custom Accessibility Features:
- Custom interactive features (e.g., custom menus or JavaScript-like interactions in Google Slides) may lack robust ARIA tagging or keyboard navigation.
- Solution: Transition to software like PowerPoint or InDesign, which allows detailed accessibility tagging.
- Color Contrast and Design Issues:
- Google Sheets and Slides allow some color customization, but there are no built-in tools to check and enforce WCAG-compliant contrast ratios.
- Solution: Use external contrast-checking tools or design software with integrated accessibility checks (e.g., Figma or Adobe XD).
- Non-Compliant Form Design in Google Forms:
- Google Forms often falls short in supporting accessible error identification, labels, or custom ARIA roles. Advanced forms with full WCAG compliance may require a platform like Microsoft Forms or a web development environment.
- No Detailed Accessibility Auditing:
- Google Workspace apps do not provide native tools for auditing accessibility across documents or designs.
- Solution: Use external auditing tools such as WAVE or Axe to identify and resolve WCAG violations.
- Language and Multilingual Accessibility:
- Google Docs supports some basic language tagging but cannot fully address accessibility for multilingual documents with specific pronunciation or semantic needs.
- Solution: Use advanced editing tools that allow precise language tagging, like Microsoft Word or InDesign.
How to Decide When to Move to a Different Program
You should consider moving away from Google apps when:
- The task involves a critical WCAG violation that Google Workspace cannot address (e.g., no alt-text for key visuals or inaccessible interactive content).
- External auditing tools consistently flag issues that cannot be resolved using Google’s built-in accessibility options.
- You need advanced customization or integration of assistive technologies (e.g., full ARIA implementation, detailed tagging, or robust form accessibility).
Example workflows:
1. Document Accessibility in Microsoft Word
- Why Word? Microsoft Word has advanced accessibility tools, including a built-in Accessibility Checker and robust support for semantic structure (e.g., heading levels, alt text for images, table summaries).
- Example Workflow:
- Use Word’s Styles feature to apply semantic headings (Heading 1, Heading 2, etc.).
- Add alt text to images by right-clicking the image > Edit Alt Text.
- Use the Accessibility Checker (Review tab) to identify and fix issues such as missing headings or poor color contrast.
- Export to a tagged, accessible PDF using Save As PDF with the “Create Accessible PDF” option.
2. Presentation Accessibility in Microsoft PowerPoint
- Why PowerPoint? PowerPoint includes tools to ensure slide layouts are screen-reader-friendly, proper reading order, and video captioning.
- Example Workflow:
- Use built-in slide layouts (e.g., Title Slide, Content Slide) to ensure proper semantic structure for screen readers.
- Add alt text to all images, charts, and graphs.
- Use the Accessibility Checker (Review tab) to catch issues like insufficient text contrast.
- Add closed captions or subtitles to embedded videos via the Insert Captions feature.
3. Data Accessibility in Microsoft Excel
- Why Excel? Excel is more screen-reader-friendly than Google Sheets and offers features like named ranges and accessible pivot tables.
- Example Workflow:
- Use Named Ranges instead of referencing raw cell coordinates (e.g., =SUM(SalesData)).
- Add descriptive headers to all columns and rows for better navigation.
- Use the Accessibility Checker to identify common issues like merged cells, which can confuse assistive technologies.
- Export to a PDF with accessibility tags to retain structure.
4. Accessible PDFs with Adobe Acrobat Pro
- Why Acrobat Pro? It’s the industry standard for ensuring that PDFs are fully accessible, with tools for tagging, alt text, and reading order adjustments.
- Example Workflow:
- Import your document from Word or PowerPoint and open it in Acrobat.
- Use the Accessibility Tool to run a full check of your document.
- Fix issues such as missing tags, reading order problems, and alt text directly in Acrobat.
- Verify compliance with the built-in Accessibility Checker.
5. Form Accessibility in Microsoft Forms or JotForm
- Why These Tools? These platforms provide greater control over form labels, field instructions, and error messages than Google Forms.
- Example Workflow:
- Add clear and descriptive labels to every form field.
- Include placeholders or instructions for input requirements (e.g., “Enter your 10-digit phone number”).
- Enable validation for required fields with error messages.
- Test the form with screen readers to confirm navigation and readability.
6. Design Accessibility in Figma or Adobe XD
- Why Figma/Adobe XD? These tools allow detailed accessibility checks during the design process, including color contrast and interactive elements.
- Example Workflow:
- Use plugins like Contrast or Stark to ensure your color palette meets WCAG contrast requirements.
- Annotate designs with accessibility notes (e.g., “This button must have ARIA role=’button'”).
- Export designs with accessible descriptions for developers to implement.
7. Website Accessibility with WordPress
- Why WordPress? WordPress supports accessibility-ready themes and plugins to ensure WCAG compliance for websites.
- Example Workflow:
- Choose an accessibility-ready theme (marked in the theme directory).
- Use plugins like WP Accessibility to add ARIA roles, skip links, and other enhancements.
- Test the site with tools like WAVE or Axe to identify accessibility barriers.
8. Interactive Accessibility in ARIA-Supported Development Environments
- Why Use ARIA? For custom interactive content, ARIA (Accessible Rich Internet Applications) helps ensure assistive technologies can interact with dynamic elements.
- Example Workflow:
- Develop interactive content in HTML using ARIA roles (e.g., role=”dialog”).
- Use tools like Deque Axe or Google Lighthouse to test ARIA implementation.
- Include keyboard navigation testing to ensure all users can interact with your content.
Are you using Federal money in your work at SBU?
You may have personally signed to assure that these standards are being met. The text in federal grants typically references compliance with federal accessibility laws, such as the **Rehabilitation Act of 1973 (Sections 504 and 508)** and the **Americans with Disabilities Act (ADA)**. When an individual or institution applies for or accepts federal grant money, they agree to meet certain accessibility standards. While the exact wording may vary across different grants and agencies, the agreement usually includes language to the following effect:
—
### Example General Language in Federal Grant Agreements:
1. **Compliance with Federal Laws:**
“The recipient agrees to comply with all applicable federal laws, including the Rehabilitation Act of 1973, as amended (29 U.S.C. §§ 794 and 794d), which prohibit discrimination on the basis of disability in programs and activities receiving federal financial assistance and require the provision of accessible electronic and information technology.”
2. **Affirmation of Accessibility Efforts:**
“The recipient certifies that all programs, services, activities, and facilities funded under this grant will be accessible to and usable by individuals with disabilities in accordance with applicable laws, regulations, and guidelines.”
3. **Continuous Accessibility Improvement:**
“The recipient affirms its ongoing commitment to advancing accessibility in its programs and services and to the development and implementation of strategies to achieve compliance with accessibility standards, including but not limited to WCAG 2.1 AA, Section 508, and ADA Title II and Title III.”
4. **Reporting and Accountability:**
“The recipient agrees to monitor compliance with accessibility requirements and to submit periodic reports as requested by the funding agency to demonstrate ongoing efforts and progress toward full accessibility.”
—
### Key Takeaways:
– **Federal Compliance:** The university must demonstrate compliance with Section 504 (general nondiscrimination) and Section 508 (electronic accessibility for federal funds recipients).
– **Commitment to Accessibility:** Grant recipients affirm that they are actively working toward full accessibility in all operations impacted by federal funding.
– **Accountability:** Granting agencies may require documentation or assurances demonstrating these efforts.
And of course, even if you yourself have not signed such an agreement, the university itself takes federal money to operate. At least for now.
Getting PDFs ready for Accessibilty Requirements
The compliance of scanned and OCRed files from Adobe Acrobat Pro with accessibility standards depends on several factors, especially when dealing with complex layouts like columns and tables. Here’s how these elements fare:
1. Text Recognition (OCR) Accuracy
- Adobe Acrobat Pro’s OCR is generally reliable for converting scanned images into editable and searchable text.
- Challenges with Columns: OCR might misinterpret multi-column layouts, reading them linearly rather than by column.
- Challenges with Tables: OCR may struggle to preserve the structure of tables, often interpreting them as unstructured text.
2. Tagging and Accessibility
Acrobat Pro can automatically tag OCRed documents, but the tags may not always be accurate, especially for complex layouts:
- Columns: Acrobat might not detect column order correctly, causing screen readers to read content in the wrong sequence.
- Tables: The software often fails to generate proper table tags, leading to a loss of row and column relationships crucial for screen reader users.
3. Alt Text for Images
- Scanned documents often include graphical elements, which Acrobat cannot automatically assign alt text to. You must manually add descriptive alt text for meaningful images.
4. Reading Order
- Acrobat’s “Reading Order” tool is essential to correct the logical reading sequence, especially in multi-column and table-heavy documents.
- Default reading order for OCRed files may require significant manual adjustments to ensure compliance.
5. Compliance with Accessibility Standards
To meet accessibility standards like WCAG 2.1 or Section 508, additional steps are often necessary:
- Manually Adjust Tags: Verify and edit tags to accurately reflect document structure, including headings, lists, tables, and columns.
- Use Acrobat’s Accessibility Checker: This tool helps identify and fix accessibility issues but may not catch all problems in complex layouts.
- Supplement with Manual Efforts: Complex documents may require manual remediation with tools like Adobe Acrobat or third-party software specialized in accessibility.
Best Practices for Improving Compliance
- Pre-OCR Processing: Clean up scanned files to enhance OCR accuracy (e.g., ensuring straight scans, good contrast, and minimal noise).
- Use Proper OCR Settings: Select the correct language and enable the “Recognize as Table” option where applicable.
- Manually Review Tags: After OCR, manually inspect and adjust tags for accurate representation of document structure.
- Simplify Layouts: If possible, avoid overly complex layouts in scanned documents to minimize accessibility challenges.
By taking these additional steps, you can significantly improve the compliance of scanned and OCRed documents, even with complex layouts.