Accessibility of Web Apps For a while we've been striving to write web apps that would be usable by screen readers for people who have visual impairment. Fedora Community was a solitary exception to this as it was seen as merely aggregating apps that were provided elsewhere. However, this year, we've had more apps start to rely on javascript that manipulates the DOM (tagger comes to mind). This is a problem for screen readers as there are no open source screen readers that I know of that enable this functionality reliably (elinks is the closest. It links to spidermonkey for a javascript interpreter. However, it only implements bits and pieces of the DOM it's extremely unlikely to work with anything useful.) I think it's time to re-evaluate what we want to strive for in terms of accessibility. Here's the options I've come up with. Feel free to come up with other options :-) * Stop worrying about accessibility - We can use whatever works in our standard graphical browsers since we no longer target people who cannot use them with (up to) all five senses. * Continue to target screen readers for things we write - Unless someone can find some better news than I've been able to, this means, among other things, having fallbacks for pages in apps that use javascript, imagemaps, or other things that don't work in text-mode browsers so people using screen readers have a method of accessing the same functionality. This is usually implemented by rendering the fallback as the html page. Then having javascript replace the contents of the page with whatever is needed to implement the more dynamic view. * Continue to target screen readers but only for things we consider in "the critical path" - Critical path has been loosely defined as things that are used to build and push out packages. pkgs.fp.o, koji, bodhi, fas are the obvious ones. pkgdb and tagger are currently in a grey area of we'll-survive-without-but-they-probably-should-be-included. wiki (editing) and mirrormanager (admining mirrors, not downloading via) are examples of things that are not in the critical path. * Discard accessibility for screen readers in the WebUI where we provide a terminal-app that does the same thing. - This would assume that people using these web apps are using Fedora. Then again, there might be other methods besides screen readers to access web pages with javascript on other platforms? * Assume that blind users can use standard desktop apps (like firefox and webkit based browsers) to access our web apps as long as the apps provide keyboard navigation. - I don't know if this is a reasonable expectation on Fedora. Need to talk to someone who works on accessibility to know if this is a viable option for blind users, for a subset that are vision impaired but not totally blind, or of no use at all. - We'll also need to think about how to make keyboard navigation discoverable and perhaps settle on some standard keybindings. I haven't checked the current state of all our applications in elinks recently but I did just do a spot check. pkgdb and tagger and both are currently unusable for their editing functions (tagger I couldn't even log in). FAS worked. koji I suspect will work for read-only views. For read-write it may work if there's a way to have elinks use the fedora client-side certificate. -Toshio
Attachment:
pgpzbJR7kHuQ7.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure