[sugar] [laptop-accessibility] Automated testing of activities

Wed Jul 18 10:57:23 EDT 2007

Just 2 cents on localization and textless environments etc.

I cannot answer all your questions but a few comments might help with some.

If sound-based icons can be used, brief sounds that identify an item might
allow you to avoid using words. Having said that, a blind kid can easily
learn a few words in English or any other language in order to identify
icons, the same blind kid can get used to an English or Spanish or any other
language synthesizer mangling his own language if that's all what is
available.  eSpeak and others are just not going to have all the languages
you need, although I hear it is not that difficult to add languages. You
just need to mobilize local contacts to help you.

Compared to the end users of these laptops I am a rich blind Westerner and I
listen to Portuguese texts with an English synthesizer on a daily basis
because it is just faster when working with multiple languages.

What I am trying to say, even if not very eloquently, is: Please give blind
kids the ability to listen to text on their screens.  Compared to nothing, a
screen reader that pronounces things poorly, does not give access to drawing
programs, and occasionally crashes, is paradise.

Just being abel to read and write on a txt editor, and read whatever the
browser shows and lick on links will be revolutionary for them.  If an
adaptation of Orca, LSR, Gnoppernicus, or creating something from scratch is
best, I do not know, but please figure something out guys.

It is certainly a bit late in the game to be talking about this, but hey, we
are talking.  The end result will almost certainly not be at par with the
quality of the rest of the system, given the tight deadlines you correctly
highlight, but what else is new.  The disabled have been dealing with being
a lower priority since the beginning of time.

Please, do not let your high software development standards prevent
something simple that speaks and magnifies from being shipped.

Finally, this is not a criticism of you guys as I consider it a failure of
many.  Just like I failed to get through to the right people earlier when it
would have been easier. Large well funded organizations that focus on
blindness apparently also failed or never tried.

-----Original Message-----
From: accessibility-bounces at lists.laptop.org
[mailto:accessibility-bounces at lists.laptop.org] On Behalf Of Kent Quirk
Sent: Wednesday, July 18, 2007 9:36 AM
To: jg at laptop.org
Cc: accessibility at laptop.org; OLPC Developer's List; Sugar List
Subject: Re: [laptop-accessibility] Automated testing of activities

Please don't read this as me objecting to the concepts of automated testing
or accessibility support -- I'm generally in favor of both. But they can
have pretty major implications, especially on schedules.

Many questions:

When you say "accessibility" you mean "support for vision-impaired users"?
Are there other accessibility requirements?
What in particular are the requirements? Support for a screen reader? 
Large fonts? Zoomable screen? Will there be a screen reader application for
the system? Where is it coming from, and how will it interact with
activities?
How does the accessibility interact with the intent to support localizable
or localization-free activities, in large part by leaving text out of the
interface entirely? What is a textless application supposed to do in this
environment?
What parts of the system are going to have to comply with this requirement?
The mesh view, for example? The clipboard? What about, say, drawing
activities? The record application? Games?

Is automated testing intended for more than just battery life testing? 
If not, is it really necessary for every activity to support it? If so, what
do you expect to accomplish? Will it actually save more than the amount of
time taken to implement it for a given activity?

What are the time constraints?

The potential scope is huge...it would be nice to understand the actual
requirements.

   Kent

Jim Gettys wrote:
> I want to give everyone a heads up to start thinking about the 
> following
> issues:
>
> 1) we need to be able to do basic automated smoke testing of activities.
> 2) we need to support accessibility in activities.  Some of you may 
> not be aware of it, but this is a non-optional requirement of some 
> jurisdiction, most of which roughly follow US government laws in this 
> area.
> 3) we need to be able to quantify improvements/regressions in 
> activity's energy usage, as we optimize various code in our system.
> 4) we need to be able to automate testing of realistic workloads (or 
> play loads :-), of our systems that roughly simulate the use of a 
> child in school, so we can see how we're doing when we change various 
> knobs that we have for controlling power usage, from backlight, to use 
> of the dcon, to blanking the screen, to suspending aggressively, etc.
> Applications adding hints in key locations that suspending might be a 
> good thing to do are also becoming possible, as our power management 
> infrastructure improves.
>
> But if we can't reproduce results, we'll be in fog, unable to see what 
> direction to go.
>
> We'll therefore need to be able to script applications.  So long as 
> we're on an XO-1 with its resolution screen *and* you don't change the 
> UI, it's not all that hard.  But we expect all of you to want to tune 
> your UI's, and also we need to ensure accessibility needs get met.
> Future systems our software runs on may have different screens; this 
> model will break down pretty quickly.
>
> Note that the hooks required for accessibility hooks makes it possible 
> to script activities by name, rather than by X/Y coordinates on the 
> screen, and wait for results, and that this technology therefore can 
> remove the screen resolution dependence of such scripting.  Custom 
> widgets you build will need such hooks, in any case.
>
> We'll shortly be setting up a battery life testing infrastructure in a 
> revived Tinderbox; with the machine we have with instrumented with > 
> 20 measurement points we can gather great amounts of useful 
> information on the behavior of our system and of individual activities.
>
> At some point, we'll start asking you to generate a workload for an 
> activity, which should be able to address many of the issues above.
> More when the infrastructure work is further along.
>
>                                - Jim
>
>   

--
------------------------------------------------------------
Kent Quirk           I'm making a game about global warming.
Game Architect                        Track the progress at:
CogniToy                http://www.cognitoy.com/meltingpoint

_______________________________________________
accessibility mailing list
accessibility at lists.laptop.org
http://lists.laptop.org/listinfo/accessibility