[Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
ted at ubuntu.com
Thu Feb 10 05:39:08 CET 2011
I forwarded the discussion that was had about using the title in the
tooltip for the accessible label. While I felt that it was not adequate
I couldn't express why. As per usual, mpt says it better than I, here
is his response:
-------- Forwarded Message --------
From: Matthew Paul Thomas <mpt at canonical.com>
-----BEGIN PGP SIGNED MESSAGE-----
Ted Gould wrote on 08/02/11 20:23:
> Do you have thoughts on this from the a11y perspective? They want to
> use the title of the tooltip for the accessible label. It seems to me
> that would be sub-optimal, but if so I need a good reason :)
1. Expert screenreader users will, if they can, save time by listening
to only the first part of an item's label before navigating
elsewhere. So an accessible label may put variable information
first (for example, "22 percent battery"), while the tooltip may be
better presenting the same information in key-value form (for
example, "Battery (22%)").
2. A smart human reading something aloud will often expand
abbreviations. A screenreader often won't understand the context
well enough to do this, so an accessible label may pre-expand
abbreviations instead. For example, whereas a tooltip may compactly
say "Battery (4:05 remaining)", an accessible label might better
say "4 hours 5 minutes battery remaining". (Luke may want to
correct me on this.)
3. Some things that need to be conveyed in accessible labels would be
utterly redundant in tooltips. For example, something like Ubuntu's
session menu needs an accessible label "Session" to briefly
identify it. But if we were giving our menus tooltips, "Session"
would be rather useless; a better tooltip would be something like
"Commands for exiting Ubuntu".
> examples anywhere I could point to?
Images in HTML. After a long struggle, accessibility advocates finally
got most browsers to treat alt= (the accessible equivalent) and title=
(the tooltip) differently, to help Web authors understand that what's
good for one is rarely good for the other.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110209/a4553a17/attachment.sig
More information about the Plasma-devel