Re: Bug#855446: debtags: Adding more accessibility tags
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,
> 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
> 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
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.