Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
On Thu, Feb 10, 2011 at 4:39 AM, Ted Gould t...@ubuntu.com wrote: 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%)). This is a great example, and suggests that we also need this information included within the spec - ie. the distinction needs to be made clear to developers using it. If we don't make it clear then we'll end up with developers simply reusing the tooltip text anyway! Cheers Rich. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron J. Seigo wrote on 03/03/11 19:53: On Thursday, March 3, 2011, Matthew Paul Thomas wrote: Aaron J. Seigo wrote on 03/03/11 06:15: On Tuesday, March 1, 2011, Matthew Paul Thomas wrote: ... But in general, while all interactive graphic-only elements should have accessible labels, not all of them need tooltips. example? Icon-only labels at opposite ends of a slider: for example, muted at one end and maximum-volume at the other, or low-zoom at one end and high-zoom at the other. The icons should have accessible labels, but to a sighted user they are obvious enough that tooltips would be silly. (If they weren't obvious enough, the correct fix would be to make the labels plain text, as slider labels often are, not to give them tooltips.) i was hoping for examples relevant to the topic at hand, namely status notifiers / app indicators. :) You asked for an example of my in general point, not of status notifiers in particular. For status notifiers in particular, as you may know, Ubuntu's design position is that the answer to which app indicators should be obvious enough not to need a tooltip is all of them. ... If the syntax had been img src=...alternate/img, it would have been much more obvious that an alternate was expected and what it was for. Sure, some people would still have routinely written img src=.../img. But fewer people would have, because it would have been more obvious that that was missing something than that img src=... is missing something. img src=http://idontcare.com/haha.png; / :) most API is abusable, and app developers will do just that. a truly crappy part of reality. We're not disagreeing. The fact remains that a well-designed API will be used in good ways more often than a badly-designed API. An API that makes accessibility obvious will be used accessibly more often than one that makes accessibility non-obvious. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk16WSYACgkQ6PUxNfU6ecrctQCeMipT99JLeyPtzJd+a3NINzcO G9EAn0Kp/KOVnfGFoyUpIGEfR9WLI0x4 =fzlb -END PGP SIGNATURE- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron J. Seigo wrote on 03/03/11 06:15: On Tuesday, March 1, 2011, Matthew Paul Thomas wrote: ... But in general, while all interactive graphic-only elements should have accessible labels, not all of them need tooltips. example? Icon-only labels at opposite ends of a slider: for example, muted at one end and maximum-volume at the other, or low-zoom at one end and high-zoom at the other. The icons should have accessible labels, but to a sighted user they are obvious enough that tooltips would be silly. (If they weren't obvious enough, the correct fix would be to make the labels plain text, as slider labels often are, not to give them tooltips.) ... In a survey by Opera Software of 3,219,487 Web pages that used the img element, 2,520,939 of them (78%) used alt=, while 367,132 (11%) used title=. http://dev.opera.com/articles/view/mama-images-elements-and-formats/#img As far as I know, there are no public statistics on how often img elements have distinct alt= and title= values. But we can conclude, at least, that Web authors care enough about accessibility to provide accessible equivalents most of the time. after years of getting it pounded into their heads and with the added bonus that this text is often used for things like tooltips ... they still fail 11% of the time. ... That is because the img API was apparently designed without any thought for accessibility. http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element If the syntax had been img src=...alternate/img, it would have been much more obvious that an alternate was expected and what it was for. Sure, some people would still have routinely written img src=.../img. But fewer people would have, because it would have been more obvious that that was missing something than that img src=... is missing something. http://sweng.the-davies.net/Home/rustys-api-design-manifesto So I think it is important to bake accessible labels into the API in a way that makes it obvious that they are needed, even for things that shouldn't have tooltips. http://behindthecurtain.us/2010/06/12/my-first-week-with-the-iphone/ - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1v5oEACgkQ6PUxNfU6eco0iwCgguPHPPa99u+NupQP7VF3F0Bb Gt0An3QkHeQgxUYM2Fl4A+o77cdg1rCr =yE+G -END PGP SIGNATURE- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
On Thursday, March 3, 2011, Matthew Paul Thomas wrote: Aaron J. Seigo wrote on 03/03/11 06:15: On Tuesday, March 1, 2011, Matthew Paul Thomas wrote: ... But in general, while all interactive graphic-only elements should have accessible labels, not all of them need tooltips. example? Icon-only labels at opposite ends of a slider: for example, muted at one end and maximum-volume at the other, or low-zoom at one end and high-zoom at the other. The icons should have accessible labels, but to a sighted user they are obvious enough that tooltips would be silly. (If they weren't obvious enough, the correct fix would be to make the labels plain text, as slider labels often are, not to give them tooltips.) i was hoping for examples relevant to the topic at hand, namely status notifiers / app indicators. :) In a survey by Opera Software of 3,219,487 Web pages that used the img element, 2,520,939 of them (78%) used alt=, while 367,132 (11%) used title=. http://dev.opera.com/articles/view/mama-images-elements-and-formats/#im g As far as I know, there are no public statistics on how often img elements have distinct alt= and title= values. But we can conclude, at least, that Web authors care enough about accessibility to provide accessible equivalents most of the time. after years of getting it pounded into their heads and with the added bonus that this text is often used for things like tooltips ... they still fail 11% of the time. ... That is because the img API was apparently designed without any thought for accessibility. true ... but: If the syntax had been img src=...alternate/img, it would have been much more obvious that an alternate was expected and what it was for. Sure, some people would still have routinely written img src=.../img. But fewer people would have, because it would have been more obvious that that was missing something than that img src=... is missing something. img src=http://idontcare.com/haha.png; / :) most API is abusable, and app developers will do just that. a truly crappy part of reality. -- 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
Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
On Tuesday, March 1, 2011, Matthew Paul Thomas wrote: I understand that it's suboptimal (though thanks, Matthew for laying it out in greater detail), my reservation was that many developers simply don't care about accessibility enough to add another string, so it probable makes sense if the accessible label falls back to the tooltip when the developer forgot to specify the accessible label. In the particular case of StatusNotifierItem, KDE developers may decide for consistency that they should always, or (as in Ubuntu) should never, have tooltips. irrelevant, as this is something decided on the visualization side, not something the application developer needs to worry about. But in general, while all interactive graphic-only elements should have accessible labels, not all of them need tooltips. example? 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. Exactly, and how many websites end up with this distinction correctly implemented? ... In a survey by Opera Software of 3,219,487 Web pages that used the img element, 2,520,939 of them (78%) used alt=, while 367,132 (11%) used title=. http://dev.opera.com/articles/view/mama-images-elements-and-formats/#img As far as I know, there are no public statistics on how often img elements have distinct alt= and title= values. But we can conclude, at least, that Web authors care enough about accessibility to provide accessible equivalents most of the time. after years of getting it pounded into their heads and with the added bonus that this text is often used for things like tooltips ... they still fail 11% of the time. colour me unconvinced :) -- 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
Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Kügler wrote on 10/02/11 17:22: On Thursday, February 10, 2011 05:39:08 Ted Gould wrote: ... 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: ... I understand that it's suboptimal (though thanks, Matthew for laying it out in greater detail), my reservation was that many developers simply don't care about accessibility enough to add another string, so it probable makes sense if the accessible label falls back to the tooltip when the developer forgot to specify the accessible label. In the particular case of StatusNotifierItem, KDE developers may decide for consistency that they should always, or (as in Ubuntu) should never, have tooltips. But in general, while all interactive graphic-only elements should have accessible labels, not all of them need tooltips. So thinking about it as add another string could be a bit misleading. ... 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. Exactly, and how many websites end up with this distinction correctly implemented? ... In a survey by Opera Software of 3,219,487 Web pages that used the img element, 2,520,939 of them (78%) used alt=, while 367,132 (11%) used title=. http://dev.opera.com/articles/view/mama-images-elements-and-formats/#img As far as I know, there are no public statistics on how often img elements have distinct alt= and title= values. But we can conclude, at least, that Web authors care enough about accessibility to provide accessible equivalents most of the time. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1s6NkACgkQ6PUxNfU6ecovQACfQxQArrvx3Hd/8iirN0z+XvQK AZIAnjVqiyp071ZLORODYLnkY2jjc6vI =i+4S -END PGP SIGNATURE- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
On Thursday, February 10, 2011 05:39:08 Ted Gould wrote: Plasma folks, 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 m...@canonical.com Not enough information to check signature validity. Show Details 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 :) I understand that it's suboptimal (though thanks, Matthew for laying it out in greater detail), my reservation was that many developers simply don't care about accessibility enough to add another string, so it probable makes sense if the accessible label falls back to the tooltip when the developer forgot to specify the accessible label. 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. Any 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. Exactly, and how many websites end up with this distinction correctly implemented? Anyway, I don't have any objections, just the above reservation and possible workaround. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
On Thursday 10 February 2011, Sebastian Kügler wrote: On Thursday, February 10, 2011 05:39:08 Ted Gould wrote: Plasma folks, 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 m...@canonical.com Not enough information to check signature validity. Show Details 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 :) I understand that it's suboptimal (though thanks, Matthew for laying it out in greater detail), my reservation was that many developers simply don't care about accessibility enough to add another string, so it probable makes sense if the accessible label falls back to the tooltip when the developer forgot to specify the accessible label. yeah, i have this concern as well, so let's go for: search AccessibleItemLabel if not found, fall back to tooltip title? and i would even specify in the spec that falling back is intended and fine, only labels that really have to be different from tooltips for some reason should overwrite the tooltip Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
