search

rust-lang / crates.io

The Rust package registry
https://crates.io
Apache License 2.0
2.96k stars 599 forks source link

Accessibility in package search, listing, and display #173

Closed CruzBishop closed 4 years ago

CruzBishop commented 9 years ago

I received this e-mail from Aura Kelloniemi aura.kelloniemi@nbl.fi 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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

CC @wycats

Gankra commented 9 years ago

See also:

steveklabnik commented 8 years ago

There's another issue talking about FastBoot stuff as well, https://github.com/rust-lang/crates.io/issues/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 commented 8 years ago

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 commented 8 years ago

@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 commented 7 years ago

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

Turbo87 commented 4 years ago

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 :)