2. THE NEED….
Accessibility is a human rights issue. Functional parity is not an
afterthought, a bolt on feature, or an optional enhancement.
Accessibility is a basic human right, discriminate at your own peril.
3. SOME STANDARDS
• AODA - Accessibility for Ontarians with Disabilities Act
• Web Content Accessibility Guidelines (WCAG)- W3C
• US Gov’t Department of Health and Human Services- Section 508
4. WCAG 2.0
• Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide
range of recommendations for making Web content more accessible.
• Following these guidelines will make content accessible to a wider
range of people with disabilities, including blindness and low vision,
deafness and hearing loss, learning disabilities, cognitive limitations,
limited movement, speech disabilities, photosensitivity and
combinations of these.
• Following these guidelines will also often make your Web content
more usable to users in general.
5. WCAG2.0 PRINCIPLES
• 1 Perceivable
• 1.1 Provide text alternatives for any non-text content so that it can be
changed into other forms people need, such as large print, braille, speech,
symbols or simpler language.
• 1.2 Provide alternatives for time-based media.
• 1.3 Create content that can be presented in different ways (for example
simpler layout) without losing information or structure.
• 1.4 Make it easier for users to see and hear content, including separating
foreground from background.
• 2 Operable
• 2.1 Make all functionality available from a keyboard.
• 2.2 Provide users enough time to read and use content.
• 2.3 Do not design content in a way that is known to cause seizures.
• 2.4 Provide ways to help users navigate, find content, and determine where
they are (structured content).
6. WCAG2.0 PRINCIPLES (CONT)
• 3 Understandable
• 3.1 Make text content readable and understandable.
• 3.2 Make Web pages appear and operate in predictable ways.
• 3.3 Help users avoid and correct mistakes.
• 4 Robust
• 4.1 Maximize compatibility with current and future user agents,
including assistive technologies.
7. WCAG 2.0 LEVELS
• WCAG 2.0 is divided into three conformance levels (A-AA-AAA) because the success criteria
are organized based on the impact they have on design or visual presentation of the pages.
The higher the level, the more restraining it becomes on design.
• For example, let's take Guideline 1.4 (Distinguishable), which is about making it easier for
users to see and hear content, including separating foreground from background.
• Success Criterion 1.4.1: Use of Color. Color is not used as the only visual means of conveying
information, indicating an action, prompting a response, or distinguishing a visual element
(Level A).
• Success Criterion 1.4.3: Contrast (Minimum). The visual presentation of text and images of
text has a contrast ratio of at least 4.5:1 (Level AA).
• Success Criterion 1.4.6: Contrast (Enhanced). The visual presentation of text and images of
text has a contrast ratio of at least 7:1 (Level AAA).
• WAI https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0
8. 508 COMPLIANCE
• Compliance standards are set by Section 508 of the American Rehabilitation Act of
1973 that requires federal agencies to provide software and website accessibility to
people with disabilities. When websites are 508 Compliant, they are accessible to all
users. This can mean that they are compatible with assistive technology, such as
screen readers.
• I have included 508 because there are many checklists and job aids to support
content development for Word, PDF and HTML. See
https://www.hhs.gov/web/section-508/making-files-accessible/index.html
9. ARIA- ACCESSIBLE RICH INTERNET
APPLICATIONS
• WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make
Web content and Web applications more accessible to people with disabilities.
• ARIA helps with dynamic content and advanced user interface controls developed
with Ajax, HTML, JavaScript, and related technologies. Currently certain functionality
used in Web sites is not available to some users with disabilities, especially people
who rely on screen readers and people who cannot use a mouse.
https://www.w3.org/WAI/standards-guidelines/aria/
10. QUICK WINS FOR STATIC CONTENT
• Ensure your content has a language declaration for screen readers.
• Ensure your content can be resized 200% without degradation.
• Semantically tag your content to enhance navigation through the document by readers.
• Make sure that titles for pages or screens are unique & representative of the content.
• Ensure that the reading and focus order is logical.
• Use semantic elements - headings, links, lists, roles, and tables appropriately.
• Don’t rely on color alone to convey meaning.
• Distinguish links through means other than color.
• Ensure images have alt text.
• Ensure tables are reader friendly. Avoid empty cells, spans, and nested headings.
11. PLAIN ENGLISH RULES
1. Write positive statements
2. Write short sentences
3. Write simple sentences
4. List events in sequence
5. Use parallel structure
6. Use active voice
7. Avoid gerunds at the beginning of a sentence
8. Avoid could, would, should, might, may
9. Use present tense
10. Avoid noun strings more than 3 words
11. Use approved terms
12. Avoid jargon
13. Use a determiner with nouns and noun phrases
14. Use appropriate language
12. READERS
Try running your content through a screen reader.
• NonVisual Desktop Access (NVDA) https://www.nvaccess.org/download/
• JAWS https://www.freedomscientific.com/Products/Blindness/JAWS
13. TESTING ACCESSIBILITY TODAY
• You can test the accessibility of your content today using the native tools in many editors. The US
Gov’t has comprehensive resources including checklists and procedures for testing 508
compliance:
https://section508.gov/refresh-toolkit/accessibility-testing
• Word: File > Info > Check for Issues > Check for Accessibility
• Acrobat Pro: View > Tools > Accessibility > Full Check
• Flare (following stolen from the help):
• You can use MadCap Analyzer to scan your Flare project for areas where you can improve accessibility.
See About Analyzer and Reports and Enabling Analyzer Scans.
• If you are generating HTML5, WebHelp, WebHelp AIR, WebHelp Mobile, or WebHelp Plus, the runtime
and navigation are Section 508 compliant. This helps to ensure your output's adherence to item 1194.22
of the Section 508 specification. See About WebHelp Output, About HTML5 Output, About WebHelp
Plus Output, About WebHelp Mobile Output, and About WebHelp AIR Output.
