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 label. 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
