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

2. 1. Important 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 nameagecity Michal20Bratislava Jozef25Trnava Fero19Leopoldov

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

13. 12. Table example 2 nameMichalJozefFero age202519 cityBratislavaTrnavaLeopoldov

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