One of the challenges when building government web sites is that the targeted audience range is diverse. This means we must ensure that our sites are accessible to everyone. In 1998, Congress introduced the Section 508 of the Rehabilitation Act. Therefore, implementation of accessibility measures for government sites is not just a “nice to have,” but required by law.

Section 508 was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals.

This past Saturday we attended the Accessibility Camp DC, organized by John F. Croston III. John is a web developer and accessibility advocate working with the United States Army.

The event had a great turn out of a diverse group of users, administrators, developers and accessibility consultants – many of whom rely on assistive technology – who were more than willing to share their insights. Organized in a bar camp/unconference fashion, the first activity of the event was creating a schedule of presentations and discussions from the list of suggested talks and topics on the event web site and from attendees volunteering to present or moderate. Special mention must be made of Patrick Timony the Adaptive Services Division team at the MLK Library in D.C. who generously opened their facilities to us including standard convention amenities such as chairs, gathering spaces, Wifi and power outlets but also a CART system and sign language interpreters. The CART system offered real-time captioning (provided by 2020 Captioning) projected onto a dedicated screen (the screen on the right side of the image, above) which not only increased the accessibility of the sessions (in that space) to attendees with a hearing impairment, but it also was a great tool for those of us taking notes and a perfect example of how accessible, inclusive design can increase overall usability.

Unfortunately, we couldn’t attend all of the sessions. Here are some sessions we attended:

• Web Accessibility Initative, WCAG and 508 – Shawn Lawton Henry, W3C-WAI
• Testing Techniques – Sam Johel, SSB Bart Group
• Government Project Management – Fred Simonton and James Chandler
• JAWS Screen Reader Demonstration – Jennison Asuncion
• Is Your Website Accessible? Practical Ways to Make It So – John F Croston III

W3C WAI, Section 508, WCAG 2.0 and the Differences Between Them — Shawn Lawton Henry

Shawn Henry leads worldwide education and outreach promoting web accessibility for people with disabilities at the W3C Web Accessibility Initiative (WAI). Shawn focuses her personal passion for accessibility on bringing together the needs of individuals and the goals of organizations in designing human-computer interfaces. Her recent book, Just Ask: Integrating Accessibility Throughout Design, which is available free online, offers an approach for developing products that are more usable for everyone.

Shawn’s presentation covered the history of various recommendations (standards) and policies including the Web Content Accessibility Guidelines (WCAG) 1.0, Section 508, WCAG 2.0, Authoring Tool Accessibility Guidelines (ATAG) and the differences between them. She described the process leading up to WCAG 2.0 and the “grumbling“ that followed. The community at large felt it was too full of technical jargon and didn’t contain enough real-world language. However, Shawn explained this criticism was a result of misunderstanding as this version of the Guidelines is written in technology-neutral language to better accommodate future technologies.

WCAG 1.0 focused specifically on HTML, CSS, JavaScript, PDF and Flash. In addition to the detailed Guidelines, the WCAG 2.0 document suite includes supporting materials that describe how to apply the Guidelines in technology-specific ways, such as in HTML documents. In her words, the technical standard is short – to facilitate stability – while the best practices are lengthy to be more specific.

Of particular interest to us was the discussion of the Section 508 Refresh currently being undertaken by the United States Access Board, which began in March, 2009. An audience member stated that Timothy Creagan at the Access Board said that advance notice of a public proposed rulemaking will be published later this year. When I asked Shawn how members of the community can provide feedback, she answered that there will be a window for public comment. This led to a larger discussion of how we as a community must raise issues to vendors, site owners, et al, in order to give them reasons to get accessibility prioritized within their organization.

A noteworthy takeaway from the discussion is that a stack of email messages complaining of issues sends a strong message and/or provides concrete evidence for site owners and project managers to prioritize accessibility. I added that this is especially important with the rise of purely community-based projects such as JavaScript frameworks (which are authoring tools themselves). Fortunately, the WAI is working on a document “How to report inaccessible web sites.”

Testing Techniques — Sam Johel, SSB Bart Group

Sam Johel is an accessibility consultant at the SSB BART Group in northern Virginia. His presentation described the process developed by SSB BART to quantify and qualify the accessibility of a site and the options available for testing. We hastily took down these notes during Sam’s presentation:

Automated tools

• fast, but notoriously prone to inaccurate results
• Limited to HTML/CSS pages: cannot access non-HTML media
• Unable to test the functional standards

Manual Review

• Is a code-level review
• Provides a much higher level of accuracy than automated tools
• But, it must be done by humans, so it relies on extensive knowledge on the part of the tester and potential for error
• Reviewing large volumes of code is far too time intensive

Use Case Testing

• Common to quality assurance and accessibility testing
• Involves specific tasks to be completed
• (At this point, Sam clarified that the true measure of a system’s level of accessibility is whether or not disabled users can use the system, not only complete a specific task)
• Just because a site is accessible does not mean it is compliant
• Very AT-dependent; a site may be usable with JAWS, but not ZoomText

Sam added that with the increased use of rich Internet applications, there is more need to run automated tests first (to catch the 20-25% of issues that can be identified by automated testing), then do manual testing to verify issues raised by automated tests and to find other issues. Finally, perform use-case testing (design workflows for disabled users to complete, go through system, note issues) to catch any other issues.

“We want our testing to be accurate and consistent.” SSB BART have broken down different standards (e.g., 508, WCAG) to create a checklist of criteria – to test against – and best practices to produce consistent, repeatable results and defensible criteria. “The standards will change, so we create the best practices and map those to standards.”

Government Project Management — Fred Simonton and James Chandler

Fred Simonton is an information technology specialist working at the Library of Congress and James Chandler (@uxprinciples) is a consultant working with various agencies to ensure compliance. Together, they presented accessibility from the angle of management.

Fred spoke of the issue of 508 compliance within an agency and James continued the discussion with a very thought-provoking series of questions when he asked us these questions:

1. Are you familiar with Section 508
2. If so, have you read the Federal Acquisition Regulation (FAR) rules covering 508 – where it applies, to whom and so forth?
3. According to the FAR who is responsible for specifying 508 compliance?

Fortunately for us, James laid out the responsibilities in detail – it is the role of the agency to specify the required compliance – and the risks that can be incurred if another party such as a contractor takes on that task. There was mention that it is a known issue within the federal government that 508 compliance is too-often part of acquisition document templates, even when it does not apply.

James pointed out that by not thinking about accessibility from the very beginning of project development it will end up being very costly. He stressed that it is up to the management and the developers to be aware of ensuring web sites are accessible. Otherwise, future fixes will take much more resource and time.

JAWS Screen Reader Demonstration by Jennison Asuncion

Jennison Asuncion is an accessibility consultant and a JAWS user and he gave a demonstration of some typical browsing scenarios for blind users. Fortunately for us, he slowed down the rate at which the words were read so we could follow along. He pointed out some tips, too, including (but not limited to):

• The title attribute is not read by default
• All pages are linear to a screen reader user
• Screen readers read from left to right, top to bottom

Is Your Website Accessible? by John F. Croston III

John’s presentation provided a great check list for making a website accessible and best practices. You can read his presentation in its entirety on his site. Here are some of items to check for if your site is accessible or not:

Text and Fonts

Use proper size, leading, kerning and measure.

Color and Contrast

Text less than 18pt should have a color contrast of 4.5:1, and 3:1 for bigger text. Color Contrast Checker is a great tool for checking color contrast.

Skip Nav

Skip Nav is a link (sometimes hidden) within the page that allows screen reader users to skip to main content quickly, so they’re not forced to tab through all the top links.

Tables

HTML tables should written in semantic code. The “Summary” attribute is useful to tell the screen reader what the table is about.

Forms

An accessible form should use fieldset(s), legends(s), labels on input fields, and tab indexes.

Screen Readers

There are several popular screen readers. JAWS, Window-Eyes, and the free open source Fire Vox (a Firefox extension)

Accessibility Resources

• W3C – Web Accessibility Initiative
• W3C WAI – WCAG 2.0
• Section 508
• Aaron Gustafson – http://easy-reader.net/ – blog
• Aaron Gustafson – Web Visions 07 Forms Presentation
• Derek Featherstone- http://www.furtherahead.com/
• Ian Lloyd – http://lloydi.com/
• Ian Lloyd – http://www.accessify.com
• Joe Clark – http://joeclark.org/
• Joe Clark – http://fawny.org/ – blog
• Patrick Lauke – http://www.splintered.co.uk/

Photos

We Had a Great Time!

All in all, it was a long day but we left inspired and energized. While we couldn’t take part in the after-camp festivities at the bar, we met many new people during the events and feel more connected to the community both personally and professionally. We’d like to thank John and other organizers for hosting the event, and speakers who shared their insights. We look forward to the next event!

P.S. If you attended the sessions we weren’t able to make, please share their information and materials. John has started collecting Accessibility Camp DC slides, blog posts and other links and #accesscampdc is still going strong. Let’s keep the discussion going!

Thank you.