Jean-Philippe MENGUAL, on mer. 01 mars 2017 00:18:53 +0100, wrote: > I think accessibility::accessible-with::at-spi is the most transversal tag, > and then very interesting. Other proposals you do seem for me good, but more > difficult to do: 1st because it means a package should be tested with a > specific > AT (Orca, brltty, etc).
Yes, but that's the point of the tag: knowing that somebody actually does have checked the package. Being AT-SPI-accessible is far from meaning being usable :) The problem is people trying to install software, only to realize that it's actually not accessible. At least with non-AT-SPI-accessible software, the answer is immediate :) But with AT-SPI-accessible software which are actually not usable, the user might be spending some time struggling with the software before thinking "OK, it's not actually accessible, bummer!". So that's why I'm not sure I'd want to dare putting an accessible-via::at-spi tag, it could lead people to false hopes, which is worse than nothing. Actually, we may prefer to use interface::at-spi, to express that it presents the at-spi interface, and not that it's accessible or not. > Then because it's related to a kind of disability, Yes. > then will we add, once more a11y tools will exist, dasher, civikey, > and other? Well, we would probably restrict to what is actually in Debian. Of course, depending on people's disability and requirements, the usability of the software will vary, but I tend to think that there can be a clear difference between something that is usable with e.g. Orca braille, and which can thus be recommended for a try, and something which is not, and thus excluded from trying. That can also be thought of as a way to share the set of software you do happen to be using, and that other people should probably try to use. In the case of dasher, that's not really a screen reader, so it could be doubtful that it'd be part of it. Dasher users could however still like to tag the applications which happen to work fine with dasher to input text. > With your 1st proposal, I think it's short, easy to test with a simple > accerciser > (QA could do it for example), and transversal. So I really think it's the > best. It's the best for getting something done, yes, but I'm afraid that that alone can't bring good to users, but rather frustration. Samuel
