Accessibility and Sakai 2.1: The Challenge of Accessible Tool Design Mike Elledge, Accessibility...

Accessibility and Sakai 2.1: The Challenge of Accessible Tool Design

Mike Elledge, Accessibility Team LeadGonzalo Silverio, User Interface

Developer

December 7, 2005Accessibility and Sakai 2.1: Accessible Tool Design

Introduction1. Sakai Accessibility Requirements (Mike)2. Accessibility Accomplishments (Mike)3. Sakai 2.1 Status (Mike)4. Challenges (Gonzalo)5. Solutions (Gonzalo)6. Remaining Issues (Gonzalo)7. What’s Next (Mike)8. Lessons Learned (Mike/Gonzalo)9. Q & A (Mike/Gonzalo)


Sakai Requirements

• Technical Objective: – Section 508 and WCAG 1.0 Priority One and

Two Compliant– Contained in Accessibility Style Guide

• Overall Objective: – Technical compliance– Usable


Sakai Requirements

• Specifics:– Navigation

• Consistent and varied

– Content• Predictable and meaningful

– Elements• Cascading Style Sheets • Minimal frames, • Skips, accesskeys tables• Accessibility tips and info • Title attributes• Alt attributes • Heading tags• Table, form tags


Accessibility Protocol

• Evaluation– Conversion to XHTML: Dreamweaver– Review: Firefox (Tabs, titles, CSS), Fangs

(Headings, links), WebXACT (as needed)– Review and Repair: A-Prompt; hand-coding– Validation: W3C HTML Validator


Evaluation

Tool Page A-Prompt Comment Priority Revision/Recommendation/Comment

Schedule Home--By Day—With Event Added1

Image -- Would be better to use vector images—gifs deteriorate when magnified

Headings -- Currently has one heading: Calendar by Day (h3); should add <h4> to “View;” hidden text for prior to calendar and legend of: “<h4>Calendar begins here </h4>” and “<h4>Legend begins here </h4>”

Programmatic objects require a text equivalent and will be updated when object changes

1 Don’t know

Not necessary under WCAG 2.0

Script missing Noscript section

1 Add Six Noscript alternatives?

Not necessary under WCAG 2.0

Table (data) may require markup

1 Calendar information should have headers associated with cells; add <scope=”col”> attribute to column headers

Ideally, before 8AM and After 5PM should be made part of calendar table so they can be associated properly with “Time of Day” and “Event” headers (see next comment).

Table (data) missing headers 1 Add “Time of Day” and “Event” as headers

Link text may not be meaningful

2 Main title tags should contain additional information, example: “Events before 8AM,” “Add Event,” “Merge Calendars,” “Import Calendar Information,” “Add or Revise Fields,” “Permissions for Viewing and Changing Calendar”


Schedule Page



• Evaluation

• User Testing– JAWS 6.1 and 7.0


User Testing

Tool Page Issue Desired Behavior Recommendation Importance

Announcements Add Announcement

Required items are not announced by screen reader when person tabs through form.

Required items should be identified by screen reader within form as well.

Put “Required Field” as part of <title> tag in form input box so they will be announced when person tabs through page.

Major

Add Announcement

* Body is announced as “star” when tabbing through document instead of “Body edit” and content is not read

Form should read “Body edit this is a test announcement” (for example) Ideally would say “Body copy edit.”

Works in JAWS 6.1, so not a problem

NA

Add Announcement

Radio buttons announce “Display to public” and “Display to site”

Ideally should say “Display announcement to public” and “Display announcement to site only” for greater clarity

Add appropriate <title> to form

Major

Announcements Drop down menu for View doesn’t work properly—See Global/Main Page comment

See Global/Main Page comment NA Blocker

Announcements |<, <, >, >| buttons are announced as “vertical bar button,” “button” so don’t describe what they do

Buttons should be announced as “First page of announcements,’ “Previous page of announcements,” etc.

Buttons should have appropriate <title> tags added

Critical

Announcements “Add,” “Merge,” “Options,” “Permissions” links don’t provide much context

Links should announce “Add Announcements,” “Merge Announcements,” Announcement Options,” “Permissions for Announcements”

Add appropriate <title> tags to links

Major

(View) Announcements

Drop down menu for number of items doesn’t work properly when viewing announcements

See Global/Main Page comment NA Blocker

Add Attachment User won’t know that they can choose file to upload with Browse

Screen reader should announce to user that they can use browse to upload file

File Upload Edit should be revised to read “File Upload Edit—press tab to move to Browse and select file

Major


Accessibility Testers– Sean Keegan, HTCTU for the California Community

Colleges – John Howard, Indiana University – Mary Stores, Indiana University– Rich Caloggero, MIT– Stephanie Norton, MIT– Audrey Weinland, Stanford University– Mike Elledge, University of Michigan– Gonzalo Silverio, University of Michigan– Chris Ridpath, University of Toronto



• Evaluation

• User Testing

• Results in Confluence: 2.1 Accessibility > Accessibility Results and Recommendations


Accessibility Compliance

• Older (legacy) tools mostly compliant with Section 508/WCAG One & Two– Exceptions:

• JavaScript must be enabled• Missing tags here and there• Need additional titling


JSF Compliance

• New (Java Server Faces) widgets– Don’t replicate all html functionality

• Onkeypress, <fieldset/legend>, <th id/td headers>

– Have to customize JSF to add them


Overall Usability

• “Getting better all the time…”– Still need usability enhancements:

• More informative frame, link titling• More consistent content headings• Deeper use of heading tags• Accesskeys for common functions• Still some unexpected/inconsistent tag behavior

– Refactoring of some tools for functional consistency


2.1 Status

• Accessible, if not perfect– More frequent and consistent use of

accessibility tags– Emphasis on improving navigation and

usability

• JAWS 7.0 Demo


Procedural Challenges• Development

– Distributed development– Accessibility specialists not in at first– Learning as we go along

• Post – dev review– Recommendations came from individuals– Evaluation was “tool by tool + repair” vs “element by

element + norm”– Room for interpretation– Many, many iterations


Technical Challenges--Constructs

• Reliance on problematic constructs– iFrames– Dynamic html– Presentation tables


Technical Challenges--Tools

• Legacy tools– Not modular (a change touches many files)

• Ie. Table formats• Ie. Onclick + onkeypress

– Variability (tools are all very different)– Tools are “legacy”: Contain traces of all the

decisions made through their history – including things affecting accessibility



• New JSF based tools– JSF has great accessibility hooks built in– But widgets and jsps are not obliged to use

them– A norm is still needed



• Some JSF constructs are problematic– selectManyCheckboxlist – selectOneRadio

• Both produce a table

– panelGrid– dataTable

• Complex tabular data difficult


Solutions• Portal

– IFrames• Use of invisible and visible headers (h1-h6) to stitch together the

portal /portlet content

– Accesskeys

• Tables– Removed all presentational tables– Semantic richness and consistency in tabular data tables

• Other– Alternate invisible info where appropriate

• When color / images / background image carry info• Where dhtml broke the screen reader nav model


Remaining Issues

• iFrame use

• Refresh: Great improvements made in 2.1 - but still some way to go.

• Javascript and alternates

• Dynamic content

• Being thorough – complex application –need to catch them all


What’s Next• Short Term

– Elimination of “extra” iFrame– Clean up of titling, missing tags– Heading enhancements– Accesskeys for functions

• Longer Term– Codification of accessibility—”Best Practices”– JSF customization– Tool refactoring– Learner preference content delivery (U Toronto)


Process Lessons Learned

• Building-in vs. Retrofitting: Make accessibility part of design; make design part of development

• Working Collaboratively: Carrots taste better, but take longer than sticks

• Consistency is King: Establish consistent accessibility and evaluation standards, and stick to them

• Remember Usability: Compliance is only first step


Technical Lessons Learned

• Internal norms + external guidelines + the best of intentions + retrofitting = a lot of work + error prone

• Possibilities:– Self validating code

• Against the declared doctype• Against an accessibility schema

– Accessibility views via faceless Sakai


Questions and Answers

• One question for you: Should we schedule a BOF to discuss this further?

• Your questions…


JAWS Demo

• Demo of Announcements, illustrating:– Tabbing– Accesskeys– Headings– Table summary

• Read existing announcements, add attachment, review announcement

Accessibility and Sakai 2.1: The Challenge of Accessible Tool Design Mike Elledge, Accessibility...

Documents

Transcript of Accessibility and Sakai 2.1: The Challenge of Accessible Tool Design Mike Elledge, Accessibility...