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
