Accessibility in package search, listing, and display

[CruzBishop]

I received this e-mail from Aura Kelloniemi [email protected] last night, and everybody else probably has, but since nobody's added an issue here, I might as well before I go out.

---

Hello to you the great crates.io developers,

I'm sorry that I'm spamming you all personally - I got your e-mail addresses
form crates.io's git repository logs. I decided to post to all who have
committed to the repo during the last few months, because I don't know who I
should be contacting. I can't open an issue on github, let me tell you why.

I'm blind and I use a braille display to access a computer. I would like to
use crates.io, since I've lately gotten interested about Rust. Unfortunately
the driver for my braille display (BRLTTY on GNU/Linux) only supports Linux
console, and therefore I have to use text-based web browsers (mostly elinks
and emacs-w3m). Neither of these browsers do support Ecmascript (JavaScript).
Crates.io relies heavily on JavaScript and therefore I cannot access the
package search and package information at all with my browsers.

Therefore I'm asking kindly, would it be possible to add some sort of basic
HTML-only interface to crates.io package search, browsing and information? It
does not need to be complete in any way, just some bare bones to let me (and
other blind devs) to find reusable software components for Rust. Web search
engines are a great tool for find them, but I'm afraid that robots are having
as hard time crawling crates.io as I'm having using it with elinks.

All other language's package search engines that I've seen (pypi, rubyforge,
hackage, CPAN, etc.) are accessible enough, and I really wish that crates.io
could join the club.

If you search the web, you could find out that there exists a screen reader
for the GNOME desktop (called Orca) which supports firefox. However, Orca's
support for braille is extremely limited and buggy, and using firefox is
therefore too cumbersome and slow. This situation is probably not going to
change any time soon.

Also, if you are not the appropriate persons to ask this question from, I
wish you could direct me to a mailing list to which I could post my feature
request.

And the reason why I can't open an issue on github is that github is also not
very accessible with text-based browsers. I can't create a github account.

Anyways, thank you for your time!

Best regards,
Aura

---

[tyoc213]

I have always think that programs are not think for blind people (even the accessibility is not much accesible from my POV but guess people start somewhere).

[steveklabnik]

Ember should be able to interface with most WAI-ARIA stuff just fine, but we might not be marking this up as well as we should. (though if your browser is no-JS at all, that doesn't work, of course. My understanding is that even amongst the blind, this is a very, very small number of people. Not that they shouldn't be served, mind you, but I would pursue that stuff first, as it will help more people initially)

[Gankra]

So I've been poking at this a bit in terms of WAI-ARIA -- it's not clear how to evaluate if annotations actually make the site more accessible. I'm basically fiddling around with VoiceOver and it seems to do the right think if you mash TAB today -- but not if you try to use VO-[arrow].

Meanwhile it seems like the actual issue here is a total lost cause as long as we use ember?

[Gankra]

It seems like we need FastBoot to be properly accessible to users without JS?

CC @wycats

[Gankra]

See also:

• https://www.npmjs.com/package/ember-aria
• https://github.com/trentmwillis/ember-a11y-testing/

[steveklabnik]

There's another issue talking about FastBoot stuff as well, #204

I've done a lot of work in the meantime to upgrade our Ember versions to be FastBoot compatible for when it's ready, which seems to be soon.

[bltavares]

This is not exactly the requested feature, but trying to think of another alternative that would be easier to implement and could already provide value to blind users.

Currently we already have a search feature of cargo. The only missing information that it is missing is the download count, compared to the crates.io search list.

Would it be interesting to provide more information on cargo search, maybe even a cargo search --verbose?

Feature-wise, we would also need a way to list packages, maybe cargo search --list, and a way to show information about a package, maybe cargo info <package name>.

Would those be interesting ideas, even if it is not on the browser?

[bstrie]

@CruzBishop , can you respond to Aura to let them know that this issue has been posted here? If they have a Github account at all then I think it should be possible for us to cc them in the comments, which (I think) should enable them to follow and participate in this discussion via email without having to deal with the lack of accessibility in Github's interface.

[Manishearth]

FWIW, https://github.com/Ralvke/cargo-find may help as a (better) commandline cargo search tool.

[Turbo87]

it seems that the main issue here is proving a non-JS version of the page. this will hopefully be accomplished by #1811 in the future.

since opening the issue a lot of a11y improvements have already been done and since we don't need multiple issues tracking the server rendering feature I'll go ahead and close this now :)