Application a11y certification (proposal)

[Henrik Nilsen Omma]

Hi Gary,

Gary Cramblitt wrote:
>> I've posted my ideas in the wiki here:
>> https://wiki.ubuntu.com/Accessibility/Certification
> 
> Please excuse a KDE developer for jumping in here..

First of all, I'm very happy to see a KDE developer jumping in. I'd like 
this initiative to be cross-desktop. I'll be contacting the new KDE 
usability team next.

> 
> There is already a fairly detailed methodology for testing GNOME applications 
> for accessibility here:

You are right, there is. My point is that a 'detailed methodology for 
testing' may not be the thing we need the most right now. That testing 
document has been there for a while now, but hasn't been that widely 
used or circulated AFAICT (not exactly slashdot material).

*All I want to accomplish is to get users and developers to just look at 
their applications for a second and consider the access implications.* 
In most cases that's not even happening now, and would be a big step 
forward. At the moment there is a vague idea in most people's minds that 
we have GOK, Gnopernicus and Dasher (as a sort of alibi), but are people 
aware of how much more love these need? And do they know that 
applications need to be made AT-friendly to work well with these?

Doing detailed testing is a step up from that and would be the next 
logical thing once you know that there is a problem. We need to catch 
people's interest first :) So IMO we need bug reports and possibly 
ratings, if that will help.

I wrote up a very simple set of tests a few months ago designed to 
simply get people to think about the issues. See: 
https://wiki.ubuntu.com/HandsFreeEmailing It was fairly well received; 
some people blogged about it and apparently learned some new things. I 
won't go so far as to claim that it played a major role in pushing our 
current AT team forward to it's current healthy state, but it helped. 
(btw, notice that the test document you mentioned is linked to from the 
bottom of that page ;) )

> I wonder.  Is a *rating* system all that useful?  On the one hand, it might 
> provide motivation for app authors to correct deficiencies.  OTOH, it might 
> lead to bad feelings when the ratings are thought to be "unfair".

Yep, and you are right to wonder. All I want to do is make this issue a 
more visible part of the FOSS landscape. If you think that perceptions 
of unfair ratings would be a problem, then we need to address that. 
Perhaps we can give the whole system an overall positive spin (I used 
grumpy faces in my example, which was probably bad). If we make it three 
smileys or three hugs for doing a good job then that's all positive. 
(seriously we could put some work into giving the whole thing a positive 
profile).

Frankly, the way I see it, if an author thinks he has been unfairly 
rated by the system then that's already a small win for us because it 
means he has a) thought about it and b) cares about the outcome. At this 
point I would be happy to listen to the complaints of an author and 
change his rating. If this rating system becomes so important that 
people feel the need to cheat to get a higher rating then a) we have 
succeeded beyond all expectations in gaining mind-share and b) would 
then need to consider some structural changes.

> IMHO, what app authors need are 1) clear guidelines so they don't make 
> mistakes in the first place, and 

But in the FOSS world that's often not how programs are written. First 
someone scratches a simple itch, play an ogg file in a GUI, say. When 
they think someone else might find it useful then they release it, and 
the feature requests start flowing in. Some of these get implemented 
with time. Accessibility feature requests are rare at this stage and so 
the issue doesn't get much focus when the app is initially being 
designed 'in the first place'. I guess AT might get serious 
consideration at the first complete redesign, version 2.0.

2) specific information for deficiencies in
> a form that makes it possible for the developers to address them.  The 
> Examples you give are a start towards that, but you don't provide specific 
> guidance on how testers should report deficiencies in detail and suggestions 
> for correcting them.

Right, that is important and people have been writing such guides. I 
don't want to re-write those guides because they are already better than 
I could write them :) The problem is that devs are not using them 
enough. We need to raise the general level of awareness of this in the 
whole community, among users, developers and bring in more users with 
special requirements to gives us real world feedback. And we have to 
start somewhere :)

We are talking about a boot-strapping exercise here: how to build 
something from (almost) nothing. This kind of certification system is 
based on some fairly vague guidelines, I admit that, but I'm first of 
all aiming for simplicity and to make the threshold for involvement as 
low as possible. The system can be improved as we go.

I'll wrap up with a slightly off-topic thought: two years ago myself and 
a few others launched 'Software Freedom Day 2004'. It was completely 
made up. There was no such day. We simply thought there should be. Last 
year we has something like 150 active teams in 50+ countries around the 
world going onto the streets telling people about Free Software. How 
cool is that?! We built this huge global event out of thin air, and it 
worked :) The important thing is to start. And if you start and it 
doesn't quite work, you are allowed to start again :)

- Henrik