ClearType Press - Building a Better Government Web » Accessibility http://cleartypemedia.com/press Dedicated to improving government web sites through best practices and social media. Mon, 12 Apr 2010 02:23:17 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Adobe and Open Government http://cleartypemedia.com/press/2009/11/adobe-and-open-government/ http://cleartypemedia.com/press/2009/11/adobe-and-open-government/#comments Thu, 19 Nov 2009 08:12:58 +0000 Jin http://cleartypemedia.com/press/?p=432 Adobe Open Government

If you come to Washington D.C. right now, chances are you will see big poster ads by Adobe. This is because Adobe recently launched their Open Government initiative. As stated on their web site:

As Washington takes steps to become more transparent, government departments and agencies are more openly collaborating with each other as well as the public. See examples of how Adobe technology and software are empowering the Open Government movement.

As a web designer and front-end developer working in government IT, I love the Adobe products that I use daily. However, I was surprised that Adobe built their Open Gov site entirely in Flash. Flash sites are not accessible or section 508 compliant. The best use of Flash for government web use now is to stream videos. Chris Foresman summed up the problem with Flash in his article on Ars Technica:

After just a cursory browsing, here are some of the usability and data accessibility issues we observed. You can’t select, copy, or paste any text. Your browser’s font override features won’t work, so you can’t adjust the font or its size to be more readable. Your browser’s built-in in-page search won’t work, and you can’t use the keyboard to scroll through the text. You can’t parse or scrape the data in any way; the design is fixed-width, so it’s not going to work well on different screen sizes; and browser plugins, like Greasemonkey, can’t adjust anything. Basically when it comes to text at all, if you don’t like the style or are visually impaired, you’re screwed.

Personally, I’m not anti-Flash. I believe in using the right tool for the job and Flash has its place. Rich media sites such as TV, movies, and gaming sites use it to offer their tech savvy audiences the best interactive experience. However for government sites, we need to make sure our sites are as accessible as possible to everyone out there. With the advancement in front-end development, many interactive elements can be done in pure HTML, CSS and unobtrusive JavaScript today.

The second issue is Adobe’s push for PDF format. Just about all government agencies use Adobe Acrobat to publish documents in PDF format. I have no problem with PDF for short documents. They’re printer friendly and accessible if done correctly. However, long reports can be a nightmare for both developers and the public who attempt to read them.

Clay Johnson from Sunlight Labs recently wrote a blog post titled “Adobe is Bad for Open Government.”

Take, for instance, H.R. 3200– otherwise known as “America’s Affordable Health Choices Act of 2009″, a 1017 page healthcare bill from congress. Because it is primarily published in PDF, we’ve got to build a special parser for it– that bill– in order to represent it programatically. Or Carl Malamud’s IRS filings for 527 (stealth PAC) organizations: gigabytes of PDF files, all released by government. Government releasing data in PDF tends to be catastrophic for Open Government advocates, journalists and our readers because of the amount of overhead it takes to get data out of it. When a government agency publishes its data and documents as PDFs, it makes us Open Government advocates and developers cringe, tear our hair out, and swear a little (just a little).

Clay suggests instead of PDF we should use other formats such as HTML or XML. I prefer XML since many PDFs already are built off XML format. As for HTML, I can see several issues:

  • Writing valid HTML code. Unless the people who create the files are up to date with W3C standards, we’ll end up with tons of poorly written HTML files. Many government sites are plagued with poor HTML already.
  • XML offers a structured format that can be transformed using XSL into other, more specific formats such as HTML or PDF.

I recommend reading Clay’s article in its entirety, including its comment section. Recently, Clay and Rob Pinkerton, the Director of Adobe Government Solutions, appeared on the Kojo Nnamdi Show. They offered their views in-depth on Adobe’s involvement in the Open Government movement. The audio and transcript are available on Kojo’s site.

I am happy that Adobe wants to get involved with pushing government IT forward. However, they should study the constraints government agencies face. Document format and accessibility are two important issues given the amount of data to be presented to the public.

“Accessibility” is a big word. Everyone who develops Web sites – coders and content creators alike – should aim for full compliance, but the reality is that only the criteria in Section 508 are legally binding to government. For Web-based intranet and internet information and applications (§ 1194.22 ), this means sixteen criteria and the Adobe Open Government site does not meet them. Paragraph (l) states “When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.” Unfortunately, there is text content in the HTML source of the page, but CSS is used to hide that content in such a way that it is not announced by screen readers (using “display: none“).

Adobe missed a valuable opportunity to demonstrate how Flash can be used in an unobtrusive and/or accessible way; if Adobe can’t make a Flash-based, 508-compliant site, why should we expect government developers – or any developers – to do so?

Update (12/3/2009): The Adobe Open Government site has been updated! The site still uses Flash to provide some background animations, but the content is marked up using HTML, CSS and JavaScript.

]]> http://cleartypemedia.com/press/2009/11/adobe-and-open-government/feed/ 2 Helpful Resources http://cleartypemedia.com/press/2009/10/helpful-resources/ http://cleartypemedia.com/press/2009/10/helpful-resources/#comments Wed, 21 Oct 2009 03:10:46 +0000 David http://cleartypemedia.com/press/?p=253 Web Resources

If you’re a web designer or developer working on government sites, it’s very important that you keep up with the latest web design trends and development techniques. Our field evolves at a fast pace because of new technologies as well as tips and tricks to get more out of what we already possess, whether it’s a tool or a technique. The best way to learn is through reading helpful blogs and reference sites to get informed and inspired.

In this post we’re going to share some of our favorite sites. We hope you find them useful.

Design

Graphics

Typography

Logo & Branding

Infographics

Inspiration

Showcase

Development

Front-End

Q & A and Directory

Usability & IA

Accessibility

Gov 2.0

See something we missed? Let us know in the comments!

]]> http://cleartypemedia.com/press/2009/10/helpful-resources/feed/ 4 Accessibility Camp DC http://cleartypemedia.com/press/2009/10/accessibility-camp-dc/ http://cleartypemedia.com/press/2009/10/accessibility-camp-dc/#comments Tue, 13 Oct 2009 08:00:54 +0000 David http://cleartypemedia.com/press/?p=85 Accessibility Camp DC, October 10th, 2009

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:

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

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

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 gives a demo on JAWS screen reader

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

acdc_jfc

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

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.

]]> http://cleartypemedia.com/press/2009/10/accessibility-camp-dc/feed/ 0