Accessibility and Bugzilla

[Jouni Heikniemi]

Joel et al.,

>   After playing with the developers toolbar, the question of 
> accessibility for the disabled piqued my interest.  We do not appear to 
> be very far off right now.  Many of the practices we use just for good 
> w3c validation and compatibility get us about 90% of the way to passing 
> accessibility checks.

Accessibility is one of the more controversial topics around in web 
development. I worked for Finnish state for a year, and pushing 
accessibility knowledge was one of my tasks at the time. Every project 
and initiative aimed at taking accessibility into account was almost 
doomed to fail, unless the level of accessibility desired was defined 
and decided on prior to starting.

For simple information sites with little HTML functionality, it's quite 
ok to state the aim as "We want W3C AAA accessibility" or "Let's match 
Section 508 criteria". But when it comes to a heavy specialist 
information app like Bugzilla, a little more thought is necessary. Do we 
_really_ want screen reader support? While I agree it is a socially 
responsible direction to move to, do we have sufficient knowledge and 
determination to keep things that way, once the current structures are 
changed to match some set of standards?

Also, from a practical viewpoint, would matching 508 (or WAI AAA for 
that matter) in Bugzilla be truly useful? Just as an example: One of the 
more vague rules of accessibility is using simple language. Most of 
Bugzilla installations use _very_ complex language, and even our default 
templates are pretty tough by themselves. True accessibility (as opposed 
to spec compatibility - though they may be close to one another at 
times) is a web app thing, not an HTML thing. MIME Types, requestees and 
all that stuff is tough to comprehend even for a person with a "normal" 
set of senses and brain functions. Throw in a visually impaired person 
with dyslexia, and I don't think adding some <label> elements does much.

So, my point is: Sure we can go and claim S508 of WAI conformity at some 
level. Do we actually benefit anyone by doing it, apart from us getting 
some fame and glory perhaps? Are we able to maintain that level? How? 
(accessibility is _really_ non-trivial to maintain -- we would have to 
rethink our UI review policy totally then).

 >   By and large, it seems that the biggest change is we would need to
 > change...
 > <td>Foo:</td><td><input .... id="foobox"></td>
 > to
 > <td><label for="foobox">Foo</label>:</td><td><input ....
 > id="foobox"></td>

In lines of code, maybe. In the eyes of any user most in need of the 
accessibility, I think there are worse issues. Play around with tablin 
<http://www.w3.org/WAI/References/Tablin/form> to see some; paste in a 
show_bug uri and look at the field order (<http://tinyurl.com/6ybsz> for 
an example). I'd say there is quite a lot of redesigning to be done, if 
we want Bugzilla to be _really_ accessible.

OTOH, there is little reason not to design in pro-accessibility ways 
whenever that's easily doable. Good alt texts and using form labels is 
one of the more trivial rules. That's something we should be doing even 
if we're not aiming for any formal spec conformity.


>  This represents an opportunity to continue to differentiate Bugzilla.  
> I am considering pushing towards passing the disabled access audits for 
> 2.20.  Should we take that on??

Let's talk about the reasoning and targets first. Also, let's not forget 
that none of us is - to my knowledge - a real accessibility specialist 
with lots of practical knowledge. While we can follow specs (and sure, 
I've done screen reader testing and demos in the past), it can also be a 
lot of work with relatively little practical gain. If somebody needs 
accessibility for Bugzilla, he would probably be inclined to contact us 
and co-operate. That sort of approach with somebody really focusing on 
accessibility stuff might prove more effective in the long run.

Anyway, if we decide to do something here, count me in - at least as a 
reviewer.


Jouni