Does anyone have suggestions on a way to prioritize steps in an audit
of a site for section 508?
Using web-based automated tools such as Cynthia Says as a starting off
point for further investigation is not an option as the URL is not
public facing yet.
What's an effective way to get started?
jeromecovington at gmail.com
On Tue, Sep 15, 2009 at 8:54 AM, Jerome Covington <jeromecovington at gmail.com
> Does anyone have suggestions on a way to prioritize steps in an audit
> of a site for section 508?
> Using web-based automated tools such as Cynthia Says as a starting off
> point for further investigation is not an option as the URL is not
> public facing yet.
> What's an effective way to get started?
I don't have a direct answer, but I have some good resources for you.
This is a quick run-down of what to look at. Note that 5 of the items are
for a really quick check.
Joe Dolson (@joedolson) is savvy about accessibility. He's just started a
series of accessibility review articles where he walks you through a site
review, which should give you some guidance.
WebAIM is A Good Site to bookmark for all things about accessibility. Search
their archives and forum for information. You can also follow @jared_w_smith
from WebAIM for accessibility tips. Web AIM also hosts the archives for
TEITAC at http://www.webaim.org/teitac/. TEITAC did the recent 508 update,
so they are a good resource when investigating Section 508 matters.
regards, Karen Mardahl
Also blogging and twittering at
www.stc-access.org and www.twitter.com/stcaccess
I suggest taking a look at the Web Accessibility Checklist that blind developer Aaron Cannon wrote. Cameron Moll has a post about here : http://cameronmoll.com/archives/2008/06/web_accessibility_checklist/
Then you could use the favelets that Jim Thatcher has to conduct some quick checks. I believe they only work in IE however. http://jimthatcher.com/favelets/
AccVerify is a good tool to do a more thorough check. It does have a bit of a learning curve though.
Validate first, with http://validator.w3.org/ or built-in validators
in Dreamweaver, etc. Assistive technologies can choke on poorly
formed or invalid code.
If the site's more of a content site, check:
- Navigation / links - can you reach all navigation (including nav
bar menus) via the keyboard? if not, do you have landing pages that
can be reached by keyboard as alternative to mouseover menus?
- Text - if you use images for headings, nav links, etc. do you have
alt attribute or text behind it (and is your image still readable
when zoomed in?)
- Headings - are they identified via , , etc.? That helps people jump
to different parts of the document and bypass nav menus
- Tables of data - do you have table headers identified with (CSS
classes like "heading" etc. aren't enough)
- Search, contact fields - when you have form elements, do you use
label tags or title attribute to provide labels? (preferrably visible
onscreen to help all visitors) if you have drop-down menus, can users
select from them and then select the action (e.g., select a category,
then click Go; vs. automatically moving to another place as they
- Unique labels - if you have PDFs and other doc lists, are the links
or icons labeled with unique on-screen text (preferrably) or title
attribute (so someone using screen reader doesn't har "PDF PDF
If the site's a web-based app, forms and tables for presenting
record/data collections are usually more of the beast. You'll want
to check items above, and then really go deep into the forms,
- tags are used, preferrably explicitly (e.g., labelname...
- and are used with groupings of related fields (e.g., multiple
parts to an address block, phone numbers with extensions, etc.)
- error messages and feedback can be communicated to users, possibly
via tags within the tags (set span to hidden when there's no error
message, and then set to visible when there's an error so it's
picked up by assistive technology)
- any data-dependent items (e.g., lists refresh based on selection)?
is the change downstream?
- if you're using AJAX and other RIA components, let me know and
it'd be easier to talk you through what to check
There's more (e.g., image maps, frames, etc.), but the above covers
most of the usual problems.
For what it's worth, the automated tools can help, but you're
better off with a good approach and plugins for Firefox / IE to check
things. The automated tools can give some false positives and
negatives that could be pretty critical.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
Ahh for the love of Pete - my HTML tag examples got eaten, hence the
blanks and strange things above. Please see
these tips WITH the HTML tags.