Transcript Development of Accessible E-documents and Programs for the

Development of Accessible Edocuments and Programs for the
Visually Impaired
Web accessibility testing (v2010)
1. Methods
• testing using automatic tools
• Manual testing
• Testing by a user from the target group
2. Automatic tools (A.T.)
• There are different solutions from different
vendors
• Limited online versions,
• Fully functional commercial products
• Approximately 50% of mistakes can be
caught by these tools
3. A.T. How it works
•
•
•
•
•
•
•
•
Checking syntactical aspects
are "alt" options defined?
Are all image maps client-based?
Are the row and column headers in tables
defined?
Are the frames named?
...
Heuristics
Can answer yes/no questions
4. A.T. demonstration
Mostly used tool:
• Cynthia Says:
http://www.contentquality.com/
• One page per minute / site can be tested
5. A.T. : limitations
• False positives
• Incomplete results
• not a single Priority 1 checkpoint could be
fully checked by automated testing tools
6. A.T. failures (general)
• Checkpoint 1.1 Provide a text equivalent for every nontext element
• Checkpoint 2.1 Ensure that all information conveyed with
color is also available without color, for example, from
context or markup
• Checkpoint 6.1 Organize documents so they may be
read without style sheets. For example, when an HTML
document is rendered without associated style sheets, it
must still be possible to read the document.
• Checkpoint 6.2 Ensure that equivalents for dynamic
content are updated when the dynamic content changes.
7. A.T. failures (images and image
maps)
• Checkpoint 1.2 Provide redundant text
links for each active region of a serverside image map
• Checkpoint 9.1 Provide client-side image
maps instead of server-side image maps
except where the regions cannot be
defined with an available geometric shape.
8. A.T. failures (tables)
• Checkpoint 5.1 For data tables, identify
row and column headers.
• Checkpoint 5.2 For data tables that have
two or more logical levels of row or column
headers, use markup to associate data
cells and header cells.
9. A.T. failures (miscellaneous)
• Applets and scripts: Checkpoint 6.3
Ensure that pages are usable when
scripts, applets, or other programmatic
objects are turned off or not supported. If
this is not possible, provide equivalent
information on an alternative accessible
page.
10. A.T. failures (miscellaneous)
• Multimedia: Checkpoint 1.3 Until user agents
can automatically read aloud the text equivalent
of a visual track, provide an auditory description
of the important information of the visual track of
a multimedia presentation
• multimedia: Checkpoint 1.4 For any time-based
multimedia presentation (e.g., a movie or
animation), synchronize equivalent alternatives
(e.g., captions or auditory descriptions of the
visual track) with the presentation.
11. A.T. false positives
• Automated tools frequently falsely detect
errors. E.G. www.qantas.com.au will often
be detected as an audio file without text
alternative.
• "123.jpg" can be in some situations a good
content of "alt" attribute, but tools with
some kind of intelligence may report it as
an error
12. A.T. tools
• Cynthia Says: http://www.contentquality.com/
• WebThing markup validation:
http://valet.webthing.com/page/
• WebThing Accessibility validation:
http://valet.webthing.com/access/url.html
• SSB Technologies Ask Alice:
http://askalice.ssbtechnologies.com:8080/ssb/aa
/anon/index.jsp
• WebAIM wave:
http://www.wave.webaim.org/index.jsp
13. Manual Testing
• As you seen on previous slides, there are many
situations where automatic testing fails
• Manual testing is the necessary part of web
accessibility testing
• There are many offline tools (accessibility
toolbars,...) which may help
• Mozilla Firefox Web Developer Toolbar:
http://mozilla.sk/rozsirenia/web-developer/#
• Internet Explorer Accessibility Toolbar:
http://tinyurl.com/mhus7
• Colour contrast analyzer:
http://www.visionaustralia.org.au/info.aspx?page
=628
14. Manual testing (2)
• Use toolbars from prior slide to manually
test the page
• Find the representers of groups of pages
(mainly for sites using Content
management systems)
• Disable CSS to test if document structure
exists and is defined by correct tags
(headings, item lists,...)
15. Manual testing (2)
• Disable page colours to test if the colours
are not used incorrectly
• Disable images and enable "display alt
attributes" to test relevance of your alts
• Enable "display form details" and debug
your forms
16. Testing by users from the target
group (TTG)
• This is focused mainly on usability testing
• Choose the group of testers with different
disabilities
• Think about the site which will be tested
• Find important things (which parts need to be
tested?)
• Prepare tasks for the target group
• ask them to do prepared tasks and value
successfullness, speed, measure of comfort,...
17. TTG: example
• We have to test a site of internet shop
• Target group: visually impaired people
• Registered users can search for goods by
browsing the categories or by search form
• Payment by credit card
• Question: Ideas about the target group?
18. TTG: target group
• Persons with different level of vision (blind,
color blindness, low vision,...)
• Persons with different level of internet
browsing experiences (programmers are
able to read a html so results from them
are not very relevant)
• Users of different assistive technologies
(different screen readers,...)
• question: What is important to test?
19. TTG: What to test
• Registration process (new users must
register)
• Login process...
• Operations with goods (searching,
reviewing, finding detailed information
about particular thing,...)
• Basket operations (reviewing the content,
adding and removing goods, finding
information about final price,...)
20. TTG: What to test
• Payment process
• Online help accessibility
• is the license and other important
information accessible?
• question: Ideas about tasks for testers?
21. TTG: Tasks for testers
•
•
•
•
Create a new account
Find the price of one particular thing
Is the particular thing in stock?
Buy the portable MP3 player with record button
(record function is activated by a button not from
a menu)
• Copy and paste (to an external file) some topic
from online help (E.G. using basket)
• ...
• question: how to evaluate the test?
22. TTG: evaluation
• Were all tasks realizable for all members
of the group?
• Compare time requirements of testers with
requirements estimated by specialist
• Summarization of member's comments
23. Results of testing
• The primary goal of testing is to inform
developer about problems on the site
• Resulting document must be transparent and
relevant
• It is very important to uniquely determine tested
document (url and date)
• Report must contain information about testing
environment
• More info and examples here:
http://www.informatizacia.sk/ext_dok-zaverecnasprava-pristupnost-2008-1-polrok/5112c
24. Accessibility and modern
technologies
25. JavaScript
Some accessibility issues:
• Navigation. Inability or difficulty navigating using a
keyboard or assistive technology.
• Hidden content. Presentation of content or functionality
that is not accessible to assistive technologies.
• User control. Lack of user control over automated
content changes.
• Confusion/Disorientation. Altering or disabling the normal
functionality of the user agent (browser) or triggering
events that the user may not be aware of
26. JavaScript event handlers
• Do not use device dependent event handlers
(OnMouseOver, OnMouseOut, OnDblClick,
OnKeyDown, OnKeyUp,...)
• Device independent handlers are mostly ok (OnFocus,
OnBlur, OnChange, OnSelect, OnClick(if not used on
inactive text))
• Actions of some device independent event handlers
must be analyzed to determine if they cause accessibility
problems (OnChange, OnSelect)
• It is possible to combine device dependent event
handlers to provide device independent controll of a site
but it is hard to test
• More information:
http://www.webaim.org/techniques/javascript/
32. Flash
•
•
•
•
•
The majority of Flash content cannot be
made natively accessible to screen readers
Flash content is time - based and often changes
over time
Supported only marginally and only by few upto-date versions of screen readers
Hard to track by screen readers because of
dynamic content
MSAA (Microsoft active accessibility) is
supported
33. Flash: accessibility
• Make the Flash content natively
accessible to screen readers
• Make the flash content self-voicing,
eliminating the need for the screen reader
• Provide an accessible alternative to the
Flash content
• More info:
http://www.webaim.org/techniques/flash/
34. Image CAPTCHA alternatives
(1)
• Following techniques are mainly server sided
• May not work on enterprise level
applications where spammers may target
forms specifically
• These techniques primarily stop bots and
automated spam submission programs
35. Image CAPTCHA alternatives
(2)
• Detect spam-like contents within submitted form
elements
• Detect content within a hidden form element:
• <span style="display:none;visibility:hidden;">
• <label for="email">
• Ignore this text box. It is used to detect spammers. If you
enter anything into this text box, your message
• will not be sent.
• </label>
• <input type="text" name="email" size="1" value="" />
• </span>
36. Image CAPTCHA alternatives
(3)
• Validate the submitted form values
• Search for the same content in multiple
form elements (e.g. are the first and last
name equal?)
• Generate dynamic content to ensure the
form is submitted within a specific time
window or by the same user
37. Image CAPTCHA alternatives
(3)
• Create a multi-stage form or form
verification page
• Check the referrer
• Detailed descriptions with examples are
here:
http://www.webaim.org/blog/spam_free_ac
cessible_forms /