Difference between revisions of "Orion/Accessibility"
|Line 50:||Line 50:|
* [http://www.apple.com/accessibility/voiceover/ VoiceOver] screen reader
* [http://www.apple.com/accessibility/voiceover/ VoiceOver] screen reader
* [://developer.apple.com/library/mac/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTestingApps.html ] (installed with [https://developer.apple.com/// Xcode].
Revision as of 14:20, 13 May 2015
- 1 Testing Web Accessibility
- 2 Browser Accessibility and Keyboard Shortcuts
- 3 Screen Readers and other Assistive Technologies
- 4 Automated Testing Tools
- 5 Accessible Wiki Documentation
- 6 Tips of the Day
- 7 WAI-ARIA
- 8 Web Accessibility Links
- 9 Reporting Bugs and Contributing Code
Testing Web Accessibility
A great accessibility test is to put your mouse out of reach (and/or disable your trackpad) and just use the keyboard for a while. Every time you find yourself reaching for your visual pointing device, stop and think, "Can I do this with the keyboard"? Use Tab and Shift+Tab to navigate between controls (or grouped controls, like radios), arrow keys to navigate within controls (or control groups), and Space or Enter to select or activate. Need a menu? Type Alt. Context menu? Shift+F10. Exit a menu or dialog? Esc. Zoom in/out/restore? Ctrl +, Ctrl -, and Ctrl 0 (or Cmd on Mac). List of keyboard commands in Orion? Shift+? (or Alt+Shift+? from within the editor).
Every platform and every browser has a set of keyboard shortcuts. For platform shortcuts, check out Wikipedia's Table of Keyboard Shortcuts. For browser-specific shortcuts, see the list below. If you can't figure out how to do something with the keyboard, then maybe that something needs to be fixed. If an important function takes too many keystrokes, maybe a key binding - or a refactoring - is needed. If you get lost and can't figure out where the focus is, maybe you're not drawing the focus ring, or maybe it needs more contrast, or perhaps nothing has focus - which is a fairly serious bug for a keyboard-only user.
After you become more proficient with keyboard navigation and you have ironed out any serious keyboard navigation bugs, start testing with a screen reader. Learn some of the screen reader's keyboard commands. Try listening without looking at the monitor as you navigate around your page. Does every focusable element have the label and type that you expected? Or is the screen reader saying "button" when an element you consider to be a "menu" gets focus? If you give focus to the "Create a project" text field, does the screen reader say "Create a project; Edit; type in text", or does it just say "Edit; type in text"? Think you've got this aced? Turn off your monitor and see if you can last more than 30 seconds before turning it back on.
Browser Accessibility and Keyboard Shortcuts
- Firefox accessibility and shortcuts on all platforms
Screen Readers and other Assistive Technologies
Screen readers interpret what is being displayed on the screen, and then read the information aloud or send it to a braille display to assist low-vision or blind users. Magnifiers enhance the screen with magnification and highlighting to benefit low-vision users. Inspectors are testing tools that present semantic information to developers.
- JAWS screen reader for Windows (free demo runs 40 minutes then needs reboot) (JAWS Documentation and JAWS Screen Reader Modes)
- NVDA screen reader (free, but requests donation) (NVDA Documentation and 2 great articles on using NVDA to test web applications in Firefox: Marco's NVDA Overview and WebAIM NVDA Overview)
- Narrator screen reader in Windows 8 for IE10+ (but not Firefox or Chrome) (Note that prior to Windows 8, Narrator was very basic and could only be used for rudimentary accessibility testing)
- Magnifier and other Windows tools native Windows 8 magnifier, on-screen keyboard, high contrast and speech recognition
- ZoomText magnifier/reader
- AccProbe inspector for Firefox and Chrome
- Inspect (available with Windows SDK)
- VoiceOver screen reader
- Accessibility Inspector and Accessibility Verifier (installed with Xcode).
- ChromeVox screen reader for Chrome browsers on all OS platforms
- ChromeShades inspection tool for Chrome browsers shows you visually what a screen reader user would hear
Automated Testing Tools
Automated testing tools can find low-hanging fruit, such as missing alt text on images, or pages without any headings. However automated testing does not take the place of clean design, user testing, and an understanding of what makes an application accessible.
- Colour Contrast Analyser (Win/Mac), Web Accessibility Toolbar (WAT) for Internet Explorer, and Accessibility Viewer (aViewer) from The Paciello Group.
- Contrast Ratio colour contrast checker.
- BAD: Before and After Demo shows a demo web site before and after coding for accessibility.
Accessible Wiki Documentation
Accessible documentation includes making sure that the written text can stand alone without the images. If images are used to convey meaning, then suitable replacement text needs to be supplied. Alternative text for an image in a wiki follows a vertical bar typed after the image file name, for example: [[Image:Orion-myimage.png|My Alternative Text]]. Exactly what the alternative text should say depends on the context. For example, here are HTML5: Techniques for providing useful text alternatives.
Make sure that links have meaningful text. Link text for a link in a wiki follows a space after the link url, for example: [http://www.google.com Google]. Avoid using words like here and here and here and more... and more... as link text because screen reader users rely on the link text to tell them what the link is for.
Tips of the Day
Orion committer Carolyn MacLeod wrote a very useful series of "tip of the day" messages that are a great place to get started with writing accessible web UIs.
- Whenever possible, use semantically appropriate HTML elements
- Add or augment the semantics of HTML elements with WAI-ARIA
- Every focusable element needs a name
- Use HTML5 section elements and ARIA landmark roles to semantically organize pages
- More on role="application", role="document" and role="presentation"
The W3C Web Accessibility Initiative is the overarching body that publishes the standards and guidelines for web accessibility.
Follow the ARIA Design Patterns when you are creating custom controls like a dialog, tree, breadcrumb, or toolbar.
Here is an ARIA Role, State, and Property Quick Reference.
For examples of ARIA in Orion, search for
role= in the code.
Web Accessibility Links
- The Web Content Accessibility Guidelines (WCAG) 2.0 are the standard guidelines for web accessibility.
- The Accessible Rich Internet Applications (WAI-ARIA) specification.
- WAI-ARIA Authoring Practices is an excellent best practices guide.
- The ARIA wiki is still being developed, but it has some good resources.
- Free ARIA and W3C's WAI Interest Group are email lists that can answer tough questions that google search can't answer.
- The IBM web accessibility checklist and IBM document accessibility checklist are both excellent resources providing many examples of ways to improve accessibility.
- WebAIM is a good web accessibility resource with articles and links to other resources.
- WebAxe is a web accessibility blog and podcast with news and practical tips.
- The Paciello Group is a good website containing a web accessibility blog and other resources.
- Accessibility with ChromeVox is a good overview talk on web accessibility.
Reporting Bugs and Contributing Code
Orion is an open source project. Testing, bug filing/triage, documentation and code contributions to the accessibility support are very welcome and greatly appreciated.
When you run into an issue, check the Orion accessibility bug list.
If your issue isn't in the list, file an Orion accessibility bug.
If you know how to fix it, please submit a patch.