Accessibility Seminar Notes

Following are personal notes by Lu Crabtrey on an accessibility presentation she attended in Reno, Nevada. Lu provided an overview of the presentation to the State Webmaster User Group on January 5, 2009. 


Reno, December 15-16, 2008 speaker - Derek Featherstone leads the Web Standards Project, new window. He is a former high school teacher. He now runs his web development and accessibility consultancy Further Ahead, new window, based in Ottawa, Ontario, Canada. Blog: Box of Chocolates, new window.

  • Accessibility - is for anything digital (CD's, etc) not just for the "Web."
  • Web "Content" - is anything that you place online that is designed for consumption (to be read, filled in, or used.)
  • Web sites should - enable people to solve their own problems (find solutions) – with clear writing & html.

PROGRESSIVE ENHANCEMENT is a strategy for web design that emphasizes accessibility, semantic markup, and external stylesheet and scripting technologies. (This is what “ca.gov” does.)

  1. Start with pristine semantic HTML (in a logical reading order)
  2. Add in presentation CSS
  3. Add in behavior with Javascript

YouTube video: Letter to Deaf UK, new window. The other side of accessibility.

For videos we use Transcripts, Captioning, then (in a perfect world we should use) Audio Description, new window. Listen to the Star Wars sample, or any...


Typical Problems and Suggested Solutions

  1. Knowledge gaps and awareness
    • General awareness training and specific hands-on training depending on role
    • Creating internal documentation, wiki/blog/other repository for accessible solutions/patterns
    • Reuse what works, don't repeat what doesn't (examples/templates)
    • Peer review and/or pair programming/coding
    • Internal lunch and learn sessions; working with people with disabilities, other experts.
  2. Resources for development and testing (time & budget)
    • Design Stage: test for color contrast, general layout
    • Functional Testing: all functionality must work with a keyboard only, and be easy to use; may do some testing with assistive technology for technical compatibility; Test with - iPhone & Blackberry - acts like a screen magnifier
    • Demo Testing: all alt text must be accurate & appropriate; Test with screen reader emulator, Fangs; Test with CSS, and Javascript turned off
    • Final Testing: test with real people with disabilities with varied needs, including assistive technology (usability)
  3. Third party software / vendors (awareness issues, software out of your control, hosted, or not changeable at all)
    • Vendor has a VPAT (for software)?
    • Are vendors willing to have their work/software reviewed by a third party? And will they agree to accessibility requirements as part of acceptance criteria?
    • Will vendor commit to fix items that are considered to be deficient from an accessibility perspective? (question of cost for repairs - no cost?)
  4. Need for clarity of expectations
    • What guidelines required? Section 508,  WCAG 1.0,  2.0? 
    • Build accessibility needs into personas or other User-Centered Design artifacts
    • Functional test cases that required completion of specific tasks (e.g. apply for job, contact us, get help setting up software)
  5. System wide consistency from one department to another in platforms, staff/contractors
    • Create good examples/templates that embraces best practices/accessibility - and share them with everyone
    • Distribute templates and toolkits with clear instructions on how to use them. Encourage all to test their own work along with peers. Documentation is a must.
    • Ensure that any non-html templates produce accessible content as well (e.g. Word templates used to create PDFs)

The Self-Certification Checklist (doc) is the starting point for accessibility, but the "user experience" is the end point or final test.

For Firefox users – use the Web Developers, new window tool bar to aid with testing.


web developer toolbar

For IE users – use the Web Accessibility Toolbar, new window to aid with testing. (link unavailable)


accessibility toolbar

Use Firefox add-on Fangs, new window a screen reader emulator. It creates a textual representation of a web page similar to how the page would be read by a modern screen reader (e.g. JAWS.)


fangs screen reader emulator


(These links also at Webtools, new window)
webtools


Display: none; hides from screen readers – use css instead to display off the page: -999em;

navigation hover

Web pages should be functional and usable without a mouse – by keyboard only. 
If using css for a:hover also add a:focus and a:active for keyboard only and IE.

#navigation a:hover, #navigation a:focus, #navigation a:active {
text-decoration: underline;
}
a:hover, a:focus, a:active {
color: #bc3e06;
background-color: #ecece7;
}

Keep punctuation out of links - [pdf] - screen reader verbosity settings can skip these links.
Use [<a href="this.pdf">PDF</a>] - do not use <a href="this.pdf">[PDF]</a>

Google Maps, new window (Zoom & Direction arrows) do not work with keyboard only – Derek fixed his site with custom buttons and css to place them on his Iron Man route maps, new window. (maybe ca.gov should make something similar?) 
google map, featherstone map


If a form element is properly labeled - you should be able to click on the label text to activate check boxes, focus on textboxes, etc. 
Instructions for input should be inside the label, e.g. red asterisk for required, and positioned with css.

<label for="first">First Name</label> <input type="checkbox" id="first" name="first" />

<label for="uname"><img src="redasterisk.gif" alt="required" title="required" /> User Name <em>must not contain spaces</em></label> <input type="text" id="uname" name="uname" />

label {width:17em;}
input {width:17em;}
em {width:17em; position:absolute; left:23em;}

 

   

 

If a form error occurs and there is an error message displayed – and you have focus returned to the input textbox - the screen reader (or screen magnifier) does not know what has happened – their submit takes them back – and they do not know why. Better to focus on the error message instead of the error field.


Jakob Neilsen's article F-Shaped Pattern for Reading Web Content, new window from eyetracking studies, show how people scan web pages.

f shaped pattern

Writing for the Web - The first sentence should summarize the paragraph; Get to the point right away; Put the main subject and verb at the beginning of the sentence.


HTML 5.0, new window is coming and will not distinguish between <acronym> or <abbr>. Use acronym the first time on a page, like you would with regular correspondence.

WCAG 2.0, new window (Dec. 11, 2008) is designed for progress and new technologies we haven't even invented. It is technology agnostic. It applies to everything: PDF, Flex (Adobe), AIR (Adobe), Flash (Adobe), Silverlight (Microsoft), AJAX, are all included as long as support is there…

The Section 508 refresh, new window will harmonize with WCAG 2.0, but is not due to be approved until 2010.

Google mail is searchable - instead of having to save it into folders.

One Red Paperclip, new window, demonstrates the power of the intranet. Kyle MacDonald makes 14 trades on the intranet, starting with one red paperclip and ending with a house. He is still offering to trade.


From the Target lawsuit:

<table>
<tr>
<th id="name" scope="col">Name</th>
<th id="type" scope="col">Coffee Type</th>
<th id="cups" scope="col">Cups</th>
</tr>
<tr>
<td headers="name">Joe</td>
<td headers="type">Decafe</td>
<td headers="cups">3</td>
</tr>
</table>
NameCoffee TypeCups
JoeDecafe3




Who will be sued next? Southwest.com, Oracle.com, Priceline.com - have all settled out of court.