Accessibility issues

1
Accessibility issues

• Miruna Badescu
• Finsiel Romania

2
Targeted users

• Accessibility addresses users that operate in one
  of the contexts presented below
• may not be able to see, hear, move, or may not be
  able to process some types of information
• may have difficulty reading or comprehending text
• may not have or be able to use a keyboard or
  mouse
• may have a text-only screen, a small screen, or a
  slow Internet connection
• may not speak or understand fluently the language
  in which the document is written
• may be in a situation where their eyes, ears, or
  hands are busy or interfered with (e.g., driving
  to work, working in a loud environment, etc.)
• may have an early version of a browser, a
  different browser entirely, a voice browser, or a
  different operating system

3
Web Content Accessibility Guidelines

• WAI - guidelines discussing accessibility issues
  and provide accessible design solutions
• Levels of conformance
• Conformance Level "A"
• Conformance Level "Double-A"
• Conformance Level "Triple-A the most strict
• Content developers must consider different
  situations and scenarios during page design
• being aware of specific cases helps

4
WAI Overview

• ensuring graceful transformation
• pages that transform gracefully remain accessible
  despite any of the constraints
• separate structure from presentation
• provide text equivalent for graphic and audio
  information
• create documents that do not rely on one type of
  hardware
• making content understandable and navigable
• include understandable mechanisms for navigating
  within and between pages

5
Provide equivalent alternatives to auditory and
visual content

• e.g.
• Use "alt" for elements the img, input, areas of
  map and applet elements, or provide a text
  equivalent in the content of elements like
  object, applet or SVG
• For any time-based multimedia presentation
  (Flash) synchronize equivalent alternatives
• Provide audio files when you need to detect human
  presence (prevent hackers from abusing a public
  submission)
• Use title for links only when a real
  explanation is added
• Insert meaningful page titles
• Who benefits
• Users with visual disabilities that use a speech
  synthesizer
• Search engines
• Users with poor Internet connection

6
Don't rely on color alone

• e.g.
• Text and graphics must be understandable when
  viewed without color
• Foreground and background color combinations
  provide sufficient contrast
• Dont use (just) different colors to emphasis
  text or make other structural changes
• Use safe Internet colors
• Who benefits
• Users with visual disabilities
• Users of text browsers or non-traditional Web
  access devices
• Search engines

7
Use markup and style sheets and do so properly

• e.g.
• Do not use tables when there is no tabular
  information to be displayed
• Avoid using images and use style sheets to format
  text (separate content from presentation)
• If you must use tables for layout, present your
  main content first
• Ignore spacer images and all the other images
  used for presentation (empty alt value)
• Who benefits
• Users with color blindness
• Users of text browsers

8
Clarify natural language usage

• e.g.
• Identify the language used in your page or just
  in fragments of text according to the type of
  page (XHTML, HTML4, etc.)
• Define acronyms (acronym tag) and abbreviations
  (abbr property)
• Who benefits
• Search engines
• Users with speech synthesizers and braille
  devices
• Users of text browsers
• Users even without disabilities that are un-aware
  of your context

9
Create tables that transform gracefully

• e.g.
• Tables should only be used for tabular
  information
• Make sure tables are meaningful and easy to
  follow when liniarized
• Provide summary for tables
• Mark table row and column headers accordingly
  (th, thead, tbody tags)
• Use stylesheets to define whether table headers
  should be spoken for each line or not
• Who benefits
• Users with speech synthesizers and braille
  devices
• Search engines
• Users of text browsers

10
Ensure that pages featuring new technologies
transform gracefully

• e.g.
• Verify that functionality is still available if
  you turn off Java scripts, block applet downloads
  on your machine
• Provide links to download plug-ins (PDF, SVG,
  etc.)
• Dont put sensitive information or functionality
  in elements that are not widely accessible
• Who benefits
• Users with fixed security settings
• Users with low Internet connection

11
Ensure user control of time-sensitive content
changes

• e.g.
• Do not refresh pages automatically
• Avoid automatic redirects, let users decide
• Avoid flickering and blinking
• Who benefits
• Users with visibility problems
• Tired, sick, old users

12
Ensure direct accessibility of embedded user
interfaces

• e.g.
• All elemements embedded in your page (maps,
  graphics, applets, plug ins) must follow the same
  accessibility rules
• Who benefits
• Users with speech synthesizers and braille
  devices
• Users of text browsers

13
Design for device-independence

• e.g.
• Provide client-side instead of server-side image
  maps where possible
• Verify your pages in more platforms, with
  different browser settings and with various
  output media
• Provide keyboard shortcuts to important and
  navigational links
• Provide the possibility to skip over navigation
  links
• Label form elements using the label tag
• Who benefits
• Users with speech synthesizers and braille
  devices
• Holders of non-traditional Web access devices
• Users with fixed security settings
• Users of text browsers

14
Use interim accessibility solutions

• Interim solutions specific to the nature of the
  Web
• e.g.
• Dont open new windows or pop-up windows
• Make sure that form elements immediately precede
  the control
• Include default characters in inputs and text
  areas
• Provide a linear version of tables content
• Who benefits
• Users with speech synthesizers and braille
  devices
• Holders of non-traditional Web access devices
• Users of text browsers
• Old people

15
Use W3C technologies and guidelines

• e.g.
• Declare the DOCTYPE
• Create correct markup and stylesheets
• Who benefits
• Your pages

16
Provide context and orientation information

• e.g.
• Divide large blocks of information into more
  manageable groups where natural and appropriate
• Use proper tags for structuring pages
• Look into semantically correct markup and
  usability rules
• Who benefits
• All users

17
Provide clear navigation mechanisms

• e.g.
• Dont say Click here to
• Provide a breadcrumb trail and intuitive sitemap
• Dont put too many navigational links
• Who benefits
• All users

18
Ensure that documents are clear and simple

• Read the usability rules in this direction
• Who benefits
• All users

19
Validation (1)

• Use an automated accessibility tool and browser
  validation tool
• Validate syntax (e.g., HTML, XML, etc.) and style
  sheets (e.g., CSS)
• Use a text-only browser or emulator
• Use multiple graphic browsers, with
• sounds and graphics loaded,
• graphics not loaded,
• sounds not loaded,
• no mouse,
• frames, scripts, style sheets, and applets not
  loaded

20
Validation (2)

• Use several browsers, old and new
• Use Operas capabilities to emulate other
  browsers
• Use a self-voicing browser, a screen reader,
  magnification software, a small display, etc.
• Use spell and grammar checkers
• Review the document for clarity and simplicity
  use reviewers
• Invite people with disabilities to review
  documents