AccessibleWeb@U meeting, October 20, 2005

1. Attending: Michael Gilbert, Marian Sheets, Joby Walker, Dylan Wilbanks, Patrick Michaud, Laura Baldwin, Linda Charm, Brent Holterman, Dan Comden, Rick Ells
   
2. Topic: AJAX and Accessibility
   
   1. We do have a general state and UW commitment to accessibility
      
      1. WA ISB Web Presentation Guide 5.0 Accessibility ( http://www.isb.wa.gov/tools/webguide/accessibility.aspx )
         
      2. Making UW Web Sites Accessible To Everyone ( http://www.washington.edu/computing/accessible/ )
         
   2. HTML is fairly easy to make accessible
      
      1. HTML was designed from the start to be device-independent (make the minimum number of assumptions about the client accessing the page)
         
         1. HTML is a heirarchical data structure based on a semantic model of a composition (headings, paragraphs, lists, list items, etc.). To the extent a Web page follows that semantic model, client programs can use it to help interpret and present the Web page (JAWS ability to navigate by headings is an example)
            
         2. HTML includes attributes such as ALT, LABEL, and SUMMARY that support non-graphical presentation of content.
            
      2. Use of Javascript in HTML in the past has been to keep it in an optional role (page works without it, as stated in Section 508 1194.22 standards ( http://www.access-board.gov/sec508/guide/1194.22.htm #(l))
         
   3. AJAX is new and certain ways of using it will clearly make pages inaccessible.
      
      1. AJAX code libraries are just now being developed. ( http://www.ajaxmatters.com/r/resources?id=17 )
         
         1. Microsoft is working on adding AJAX capabilities to .Net ( http://www.devx.com/webdev/Article/28530 )
            
         2. AJAX can be used in many different roles; best practices are still becoming apparent
            
      2. Accessibility problems that have been identified include the following
         
         1. Client-side AJAX can update page display without a page reload. Adaptive and assistive technology may not know what is going on.
            
            1. Change may be made anywhere in the page - how can user be made aware of what has changed?
               
            2. How can user be notified that the page needs to be reread?
               
            3. How can reread be directed to what has changed?
               
         2. Use of Focus - links, form fields, and other actionable elements should be able to receive focus so that a person can navigate to them from the keyboard. Actions should be evocable from the keyboard
            
   4. Issues and concepts
      
      1. Accessibility software usually works in conjunction with a browser (for example, JAWS is used with IE)
         
      2. Many sighted people use screenreaders - we are not just talking about people with major disabilities.
         
      3. Browser is the one that actually knows what it is displaying, not the server
         
         1. DOM is being modified, should not be up to server side to notify the client
            
      4. Distinction between text and application
         
         1. Current Section 508 guidelines generally relate to Javascript being used to control presentation of text (such as in collapsible menus).
            
            1. Currently, reload is indication to reread the page
               
         2. AJAX is more about client-side processing in which the page becomes an application which can directly send and receive information to and from the server without a page reload.
            
            1. With AJAX because changes are made in page presentation without a reload, we need an indicator to tell reader time to reread page
               
               1. Same problem with Flash
                  
            2. We lack a good set of ideas on how to design client-side processing to work well with adaptive and assistive programs.
               
            3. Providing the same functionality of a client-side application without Javascript is difficult
               
               1. To comply with Section 508, the client-side application would need to deliver the same results in "functional text that can be read by assistive technology." ( http://www.access-board.gov/sec508/guide/1194.22.htm #(l))
                  
               2. One option is to have parallel pages, one with AJAX and one without, but then you have a "back of the bus" situation which is likely to be less functional and require extra resources to maintain.
                  
3. Things people want to do
   
   1. Catalyst currently using AJAX in the background, interested in using it within pages for client-side processing.
      
   2. Compare degree programs on the fly in an interactive interface
      
   3. Simplified "control panel" to a complex process, such as a database query interface
      
      1. One large query builder form in Request Tracker (RT) has a total of 39 pull-down select lists and nine form fields, divided into three different areas on the page
         
         1. Current design is not intuitive, leading to users getting results they do not want
            
         2. Do not want to lose any of the power of the interface, as awkward as it is, if we develop an alternative
            
      2. AJAX may be helpful in situations where people have inter-related choices. Client-side processing can better present a chain of dependent choices than a complex form presenting all options for all choices.
         
4. Evaluating accessibility of an AJAX Web site
   
   1. Keyboard navigable: If you can use your Web site without touching your mouse, you are probably in good shape
      
   2. Some basic criteria and concepts from past discussions are:
      
      1. Standards-compliant: Pages that adhere to standards are easier to design assistive and adaptive client programs for.
         
         1. HTML elements have semantic meaning that assistive and adaptive clients pay attention to
            
            1. Examples: Use Headings (h1, h2, h3, etc.) to make headings and use the table heading element (th) for headings of rows and columns in simple tables.
               
      2. No mouse: A person with poor sight, no sight, or poor dexterity cannot use a mouse.
         
      3. A linear experience: Encountering a Web page with a voice browser is a linear process, progressing through the content elements in sequence or navigating by the structure of the content. A sighted person using a graphic browser, on the other hand, can take in two-dimensional spatial arrangements of content and go directly to any visible part.
         
      4. Alternatives: Provide alternative text for people who cannot see graphics or other non-text objects.
         
      5. Making connections: When you can only hear a page, it can be hard to tell which text goes with which form field or which row and column a table cell is in. Simple labelling of text and form field pairs and of rows and columns enables assistive and adaptive programs to correctly present content relationships.
         
   3. Web Accessbility Evaluation procedure ( http://www.washington.edu/computing/accessible/accessibleweb/eval_proc.html ) developed by AccessibleWeb@U provides a good basic summary of accessibility
      
   4. Can these criteria and concepts be addressed in AJAX designs?
      
5. People at the UW who need accessible design
   
   1. Dan Comden works with students at the UW with disabilities
      
      1. Dan uses a variety of technologies to help them toward their educational objectives
         
   2. Some UW staff have limited vision or are blind
      
      1. Relatively small obstacles can make it very difficult for them to do their work.
         
   3. People sometimes develop a need for adaptive and assistive technology because of injuries or health problems.
      
   4. Want to avoid design changes that prevent an otherwise competent staff person from continuing to do their job.
      
6. Usability and Accessibility
   
   1. Some approaches can make a page more usable for many people while making it less accessibility for people with disabilities
      
      1. How do we evaluate such tradeoff situations?
         
   2. When is accessibility an issue?
      
      1. Alternatives to using a Web page may be readily available in some situations
         
         1. Reporting equipment problems can be done over Web or over phone
            
   3. Can we include accessibility in the general usability design process?
      
7. Where do we go from here?
   
   1. Proposed approach
      
      1. Develop Web sites according to current standards, such as those being assembled
         
      2. For now, utilize client-side AJAX in optional and supplemental roles while we develop expertise on its use
         
         1. Explore questions of how to make AJAX designs that are functionally accessible
            
         2. Look for test project situations where we can try things.
            
      3. Develop methods to support reasonable levels of accessibility and functionality
         
         1. Identify best practices
            
         2. Share design and code examples
            
      4. Stay in active communication with each other on what we are thinking and trying.
         
   2. Dan and Rick will be working with Scott Stephenson and the DAWG group and AIS on clarifying goals and methods for accessible design.
      

Back to Top