Development of Accessible E-documents and Programs for the Visually Impaired

1. Development of Accessible E-documents and Programs for the Visually Impaired Internet browsing and accessibility

2. 1. I mportant from last session • Only keyboard is used to controll applications • Users do not have the whole screen information • Visual aspects of an application are not exposed to the users • Some non-accessible components are not important • Pictures are not accessible

3. 2 Reading the web: problems • Webpages are relatively easy to create and are often created by developers without important knowledge • All webpages are different • Many webpages often change • Webpages are often visually oriented • There are still many new technologies which may not be supported by special software

4. 3. Different strategies • Pages served without post-processing • Pages served without post-processing but screen reader (or browser) provides some special functionality for blind users • Pages are post-processed and served in special environment (a part of a screen reader, or special application)

5. 4. No post-processing • Used in "old school" MS-DOS screen readers (text browser Lynx for DOS) • page is provided "as it is" without any post-processing • There may be some special functionality (jump to next link, next heading, skip to next block of links...) • Hard to use on more complex webpages • Used mainly with Braille

6. 5. Firevox • Plugin for Mozilla Firefox • Page is accessed by elements • There are hotkeys to read contents of the active element • Miscellaneous "skip" hotkeys (jump to next / prior same element, show list of links, headings...)

7. 6. Special environments • Provided by modern screen readers (JAWS, NVDA...) • Page is analyzed and processed by screen reader • Served in special environment which provides different functionality to optimize browsing with speech (without Braille) • Processors are hard to implement because of webpages errors (missing pair tags...) • Sometimes implemented as a special browser for visually impaired • Sometimes hacks to standard browsers

8. 7. JAWS and NVDA environment • Page is served in "rich edit" as a document • Simplified to optimize browsing with speech (Braille is also supported) • Linearized version is provided • Special form mode to work with web forms

9. 8. Linearization • Multiple column pages are linearized • second column is below the first • third column is below the second... • Each link is in a separate line (user can access all links by up or down arrow) • Each form field is in a separate line • 2D components are linearized (label: form_edit is splitted into two lines...)

10. 9. Linearization (2) • Data tables are linearized row by row • Each cell is in a separate line • There is an empty line after a last cell of a row • In this way user can read a table as a 1D object • There is also a functionality to read a table in 2D form

11. 10. Table example 1

12. 11. Linearized table • name, • age, • city • Michal, • 20, • Bratislava • Jozef, • 25, • Trnava • Fero, • 19, • Leopoldov

13. 12. Table example 2

14. 13. Linearized table • name, • Michal, • Jozef, • Fero • age, • 20, • 25, • 19 • city, • Bratislava, • Trnava, • Leopoldov

15. 14. • Which version (first or second) is better and why?

16. 15. Meta information • After linearization, some meta information is added • Each heading (of course in a separate line) contains (before the text) information about the level • List of x items (with the level if it is a nested list) is added before the lists • End of list is added after the lists • Links are also described (link, this page link, sendmail link, FTP link, visited link...) • Form fields are described (checkbox, edit, password edit, multiline edit, button...) • Pictures are described by alt tag (or file name if alt is undefined)

17. 16. Examples of supporting functions • List of headings (displayed in standard listbox with level information) • List of links • List of form fields • skip hotkeys (jump to next heading, link, form field...) • Place marking: possibility to drop a placemarker somewhere in the document • ...

18. 17. Advantages and drawbacks • + enviroment optimized for the blind users • - collaboration with a sighted user is often complicated (why?) • - complicated implementation (parsing of syntactically incorrect pages...) • - environments are always bound with some concrete browser (blind users cannot use browsers used by minorities)

19. 18. Web accessibility • Why can a document be inaccessible? • Why can a document be hard to use? • Are all pictures on the webpage important? • Is a logo picture important to know about? • What is the best description of the logo of our faculty?

20. 19. Accessibility problems • important images and image links are not (or are badly) described • form fields are not correctly labeled • Data tables are complicated and not provided with meta information improving accessibility • Some parts of webpages are not accessible from the keyboard • Image captcha: There is a relatively new and usable captcha solution (Firefox plugin) which often works, but not always

21. 20. Usability problems • Non-informational images (visual separators, placeholders in table formatted webpages...) are "correctly labeled" • "mandatory fields are in red": a user can check the color but, for example * in label of mandatory fields is a better solution • Large documents without structure elements (headings, item lists...) and skip (same page) links are hard to navigate • "Live" listboxes: click on some item and something happens