3. Human ↔ Browser ↔ Web Site
1) A browser transforms content into something usable by
most users.
2) A browser also passes content into the operating
system's Accessibility API
5. Human ↔ AT ↔ Browser ↔ Web Site
Assistive technology transforms the content delivered by
the browser into a format usable by the current user.
...if that content meets accessibility guidelines.
6. Web Content Accessibility Guidelines
Four Principles of Accessibility (POUR):
1) Perceivable
2) Operable
3) Understandable
4) Robust
7. Perceivable
1) Using their available senses, a user can perceive your
content.
2) Visual elements can be conveyed in text transformed
into audio
3) Audio elements can be read as text
4) Elements can be perceived by touch through braille
8. Operable
1) Input and interaction does not depend on a specific
device, method of activating a device, or require special
coordination or timing to access.
2) If a user makes an error, they should have the ability to
recover from that error.
9. Understandable
1) Navigation should be consistent and logical
2) Language should be simple and concise, as appropriate
for the audience.
3) Alternative format and supplemental data should be
provided whenever possible.
10. Robust
All technologies employed in creating the application should
be used according to their specifications, to ensure the best
long-term interoperability with past, present, and future
technologies.
12. Screen Readers
1) Transform text content into audio
2) Transform semantic information about operation and
relationships into audio
3) Heavily use accessibility APIs
4) Limitations: cannot directly access visual sources like
video or images.
13. Screen Magnifiers
1) Enlarge view for low vision users
2) Basic magnification available from browser or OS
3) Almost entirely visual, though some have audio readers.
4) Limitations: narrow field of vision makes reading and
navigation challenging
5) Solutions: mobile-friendly web sites where you can
14. Voice Command
1) Alternative input methods for navigation and forms
2) Most products designed for executive dictation, not AT
3) Poor support for accessibility APIs
4) Limitations: if the name for a control doesn't match what
is visible, voice commands won't work on that control.
5) Solutions: ensure that the label for a button or link
15. Keyboard Navigation
1) Rare for a user to have no means to use a pointing
device
2) Many types of AT primarily use the keyboard
3) Circumstances can temporarily deny use of a pointing
device
4) Two major issues:
16. Switch Navigation
1) Family of devices with very simple input mechanisms.
2) Same general limitations as keyboard navigation
3) Switches can act like pointing devices in some
implementations.
18. Deaf and Hard of Hearing
1) Audio Transcripts
2) Video captioning and transcription
3) English may not be primary language
19. Understanding Web Accessibility
Use the four principles of WCAG 2.0 to look at any content
and consider whether it meets expectations for
accessibility.