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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kent Quirk Sent: Wednesday, July 18, 2007 9:36 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; 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 [EMAIL PROTECTED] http://lists.laptop.org/listinfo/accessibility _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
