New properties for StatusNotifierItem: Accessible Label (1/3)

Aaron J. Seigo aseigo at
Mon Feb 7 19:12:04 CET 2011

On Monday, February 7, 2011, Aurélien Gâteau wrote:
> > On Thursday, February 3, 2011, Aurélien Gâteau wrote:
> > > There are ways to strongly suggest application developers to define
> > > such strings: for example outputing warnings on stderr when a KSNI
> > > goes live without having proper a11y properties set.
> > 
> > catching and punishing sins (though a warning is hardly a punishment
> > unless
> we
> > email the devs every time it happens .. yes, i'm joking ;) is not a good
> > approach compared to being able to prevent the sins in the first place.
> > 
> > developers have every motivation to add tooltips and they usually do.
> > it's also easily tested by them: hover the entry with their mouse. if we
> > use that same data for a11y, we prevent the sins.
> Using the tooltip is a handy fallback, but it will most likely be less
> adapted to a blind reader, especially since it may contain complex HTML
> content (reminds me of another discussion...), making it much more work to
> read for a blind user than a simple, text-only, label.

so then let's fix the problem instead of creating new ones.

the title doesn't have html (notmart already noted this). no problem there, 
and that's a perfect (literally) candidate for the main "what this is" a11y 

then let's limit the html supported in the content. this can be a social 
control, just as the a11y controls would be (except in this case they'd be 
something people actually see). and if we look at all the content we have 
right now the most complex uses are of tables for aligning rows. that vast 
majority of tooltips are just simple strings.

so we might need a way to define "multiple nicely aligned rows" for content. 
otherwise, i don't see the problem in practice.

> I suggest we add the property Ted is proposing and specify that tooltips
> will be used as a fallback,

which will lead to the tooltips being used as the fallback in almost all 
cases. result? more dbus data, more spec to implement, nearly no real world 
use of that overhead. sounds like a horrible idea to me.

> but strongly recommends devs to set
> appropriate a11y labels (and output warnings in KDE implementation when
> they are not set).

you can keep wishing that this will work, but it won't. how many years have we 
been telling devs not put double margins in their dialogs? and that's 
something that they can see on their own scree. a11y is 100% invisible to 
99.<some number of 9s>% of devs.

Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : 

More information about the Plasma-devel mailing list