WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Bringing accessibility into the developmentprocess(request for feedback).

for

From: smithj7
Date: Apr 21, 2007 6:30AM

Peter I'm sorry its taken so long to reply. I really enjoyed your
article: Bringing Accessibility into the Development Process. I am
drafting a "policy" for our web content folks. I forgot the importance
of including design folks. In our organization designers are usually
part of the Communications department. They like our content folks know
little about the assessible web design. The small number of web
developers end up spending a lot of time trying to keep the multiple of
folks in their chain of command happy even though they have had 508
training. Accessiblity needs to be everyones concern.

Your tool would definitely help our web developers meet major coding
problems. Like you said on the main page of the tool, it does not
require accessiblity knowledge. The coding folks would know what the
report means. But tools like FAE (mentioned in another email) are still
needed to get the requirements. I definitely will try to get our web
developers to use your tool as a first check. It is quick and easily
understood by coders. If we had a nice clean accessible template, then
it might be the only step needed.

FYI here is the check from your report of a NEWLY designed DOE page
http://www.flbog.org/ Below it is a text version of what FAE provides.
At this point in time our web develop team would not understand the FAE
report, but understand what you are doing. But if they fixed only the
items in yours all requirements wouldn't be met. BTW, I have several of
our web folks using tools that are to internet explorer to better
understand reports like FAE. (e.g. WAVE) I am probaly the only web
person that uses FOX FIRE and I use that one a lot. WAVE is difficult
for me to understand. (I have a learning disablity and can't remember
the icons but some of the web folks are learning to like WAVE.) Our
state provides hisoft (cythia says) licenses, but for some reason the
web folks in our Department aren't using it.

missing_heading
Missing first level heading (h1). Provide at least one first level
heading describing document content.

field_missing_label
A field (with id/name 'Text2') is missing a corresponding label element.
Make sure a label exists for all visible fields.

missing_alt
Missing alt attribute for image (with src
'/images/banner/pixels_yellow.gif').

missing_alt
Missing alt attribute for image (with src
'/images/banner/pixels_red.gif').

missing_alt
Missing alt attribute for image (with src
'/images/banner/pixels_yellow.gif').

missing_alt
Missing alt attribute for image (with src
'/images/banner/pixels_red.gif').

missing_alt
Missing alt attribute for image (with src '/images/stripes.gif').

missing_alt
Missing alt attribute for image (with src
'/images/FrontPagePhotos/1.jpg').

missing_alt
Missing alt attribute for image (with src '/images/stripes.gif').

missing_alt
Missing alt attribute for image (with src
'chancellor/images/bg_rosenburg.jpg').

has_nested_tables
You have one or more nested tables.

missing_semantics
You have used font, font, font, b, b, b, b, b, b, b, b for visual
formatting. Use CSS instead.

missing_lang_info
Document language information is missing. Use the lang attribute on the
html element.

missing_th
Missing table headings (th) for table #1.

missing_th
Missing table headings (th) for table #2.

missing_th
Missing table headings (th) for table #3.

missing_th
Missing table headings (th) for table #4.

missing_th
Missing table headings (th) for table #5.

missing_th
Missing table headings (th) for table #6.

missing_th
Missing table headings (th) for table #7.

missing_th
Missing table headings (th) for table #8.

missing_th
Missing table headings (th) for table #9.

missing_th
Missing table headings (th) for table #10.

missing_th
Missing table headings (th) for table #11.

missing_th
Missing table headings (th) for table #12.

missing_th
Missing table headings (th) for table #13.

missing_th
Missing table headings (th) for table #14.

missing_th
Missing table headings (th) for table #15.

missing_th
Missing table headings (th) for table #16.

ambiguous_link_text
One or more links have the same link text ('Public Universities'). Make
sure each link is unambiguous.


Test Evaluation Summaries in HTML Best Practices Main Categories Status
1 % Pass % Warn % Fail
Navigation & Orientation Not Implemented 12 0 87
Text Equivalents Partially Implemented 0 50 50
Scripting Not Applicable 0 0 0
Styling Not Implemented 0 0 100
HTML Standards Not Implemented 0 33 66

Detail information of these categories.

Test Evaluation Percentages in HTML Best Practices Subcategories
First item percent Pass
Second percent Warning
Third percent fail
Last item percent N/A (there is a number)

Category - Navigation & Orientation
Document Title 33 0 66 0
Navigation Bars 0 0 0 100
Section Headings 0 0 100 0
Form Controls 0 0 100 0
Document Linearization 0 0 100 0
Data Tables 0 0 0 100
Frames 0 0 0 100
Access Keys 0 0 0 100
Category - Text Equivalents
Images 0 50 50 0
Embedded Objects 0 0 0 100
Category - Scripting
Device Independence 0 0 0 100
Styling
Text Styling 0 0 100 0
Content Positioning 0 0 100 0
Images 0 0 100 0
Category - HTML Standards
W3C Specifications 0 33 66 0



-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Peter Krantz
Sent: Monday, April 16, 2007 8:03 AM
To: <EMAIL REMOVED>
Subject: [WebAIM] Bringing accessibility into the development
process(request for feedback).


Hi!

First: sorry if this comes through like a shameless plug. It is not the
intention. Secondly: sorry for the long post.

I have been thnking about ways to bring accessibility into the
development process
[1]<http://www.standards-schmandards.com/2007/rapid-accessibility-feedba
ck/>and
make it a normal part of development activities. In my experience
accessibility evaluations are conducted at the end of a project. Testing
at the end makes it a lot harder to fix errors and they typically cost
more to fix.

To bring accessibility into a development project I have tried a couple
of things and discovered some challenges:

- Many developers know little about accessibility implications
emerging from their coding decisions.
- Accessibility evaluation is often conducted by experts outside the
development team.
- Aspects of accessibility (e.g. visual design, markup, content) is
not clearly mapped to areas of responsibility in a development team.

To get accessibility into the development process I have focused on
automated evaluation of markup accessibility issues. The idea is that if
you can make a basic markup accessibility check part of other automated
tests there will be alot less errors discovered at the end of the
project. Many of the existing tools today are not automatable and
require a lot of expertise to go understand the result.

For this purpose I am trying to make it possible to integrate Raakt (the
Ruby Accessibility Analysis Kit)
[2]<http://www.peterkrantz.com/raakt/wiki/>;into some of the popular
acceptance testing frameworks.

I would be grateful for your feedback on my ideas. Could this type of
basic testing be valuable? In your experience, are my observations
valid?

[1]:
http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/
[2]: http://www.peterkrantz.com/raakt/wiki/

Thank you for your time.

Regards,

Peter Krantz