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
[Fwd: Re: [Fwd: Re: New properties for StatusNotifierItem: Accessible Label (1/3)]]
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 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1SjcsACgkQ6PUxNfU6ecptswCfcvg80at8zAnXo+oGfyRpgldb GfIAoMFC4NPEJr1HFBWXy/hhesW+zP9V =A97b -END PGP SIGNATURE- 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: New properties for StatusNotifierItem: Accessible Label (1/3)
(resending, cc'ing Ted) What would help is if the tooltip was using semantic markup, instead of a subset of html. Think about something like this: tooltip titleAmarok/title icon src=amarok.png alt=Amarok/ bodyCurrently playing: Qt 4 dance by Trolltech/body /tooltip With such a format, it would be possible to extract meaningful information for a11y purpose. Heck, this could even be somehow standardized to also work for notifications (/me looks at this thread slowly drowning into markup bikeshed) title and icons are already outside the body in the spec and the title can't have html th tooltip is a single proprty, that is a struct unfolded as this icon (name or binary dump as usual) title (short, plain text, must be meaningful and always present) subtitle (optional, can have html) Ohhh... my memory is failing me. Indeed, tooltips are actually not a single field. With this in mind, I agree using the tooltip title should be good enough. What do you think, Ted? Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
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. I suggest we add the property Ted is proposing and specify that tooltips will be used as a fallback, but strongly recommends devs to set appropriate a11y labels (and output warnings in KDE implementation when they are not set). Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
Yeah, in talking to the a11y folks they like tooltips, but they really wanted another label as sometimes the tooltips don't describe the icon enough for a blind user to know what it means. this is true for traditional tooltips, but the ones in a SNI are not like those tooltips at all: they have titles, subtext, etc. they are supposed to, in an SNI, be fully descriptive. are the a11y folks aware of those differences between SNI tooltips and normal ones on e.g. pushbuttons? what this denotes to me is that maybe we need to revamp the documentation around tooltips (and as marco pointed out on irc earlier today, perhaps that was an unfortunate name to choose in the spec :/ ) so that this is very clear to app devs too. What would help is if the tooltip was using semantic markup, instead of a subset of html. Think about something like this: tooltip titleAmarok/title icon src=amarok.png alt=Amarok/ bodyCurrently playing: Qt 4 dance by Trolltech/body /tooltip With such a format, it would be possible to extract meaningful information for a11y purpose. Heck, this could even be somehow standardized to also work for notifications (/me looks at this thread slowly drowning into markup bikeshed) Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Monday 07 February 2011, Aurélien Gâteau wrote: Yeah, in talking to the a11y folks they like tooltips, but they really wanted another label as sometimes the tooltips don't describe the icon enough for a blind user to know what it means. this is true for traditional tooltips, but the ones in a SNI are not like those tooltips at all: they have titles, subtext, etc. they are supposed to, in an SNI, be fully descriptive. are the a11y folks aware of those differences between SNI tooltips and normal ones on e.g. pushbuttons? what this denotes to me is that maybe we need to revamp the documentation around tooltips (and as marco pointed out on irc earlier today, perhaps that was an unfortunate name to choose in the spec :/ ) so that this is very clear to app devs too. What would help is if the tooltip was using semantic markup, instead of a subset of html. Think about something like this: tooltip titleAmarok/title icon src=amarok.png alt=Amarok/ bodyCurrently playing: Qt 4 dance by Trolltech/body /tooltip With such a format, it would be possible to extract meaningful information for a11y purpose. Heck, this could even be somehow standardized to also work for notifications (/me looks at this thread slowly drowning into markup bikeshed) title and icons are already outside the body in the spec and the title *can't* have html th tooltip is a single proprty, that is a struct unfolded as this icon (name or binary dump as usual) title (short, plain text, must be meaningful and always present) subtitle (optional, can have html) if i read the titles and subtitles of all the icon tooltips i have in my systray i have * KGpg - encryption tool * Kopete: this one is bad since the detailed status info is in the subtitle as html, but reading the plain text should convey enough info like jabber: notm...@gmail.com (offline) MSN: notm...@gmail.com (offline) etc.. * clipboard contents - first line in the clipboard * Volume at 70% * Keyboard layout - Italy * KDE wallet - a wallet is open all of them, seem to convey quite all the informations i need if are read out loud. I would see maybe an optional field to be used instead of the tooltip *if not possibleto put enough info in the tooltip* rather the other way around. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Monday 07 February 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. I suggest we add the property Ted is proposing and specify that tooltips will be used as a fallback, but strongly recommends devs to set not the title, the tooltip title never has html. i can see at limit another property that is used as fallback, instead of the tooltip title if is not possible for some reason to encode the proper informtion in the title (thing that i higly doubt by the way) rather than having the tooltip as fallback of another property Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
What would help is if the tooltip was using semantic markup, instead of a subset of html. Think about something like this: tooltip titleAmarok/title icon src=amarok.png alt=Amarok/ bodyCurrently playing: Qt 4 dance by Trolltech/body /tooltip With such a format, it would be possible to extract meaningful information for a11y purpose. Heck, this could even be somehow standardized to also work for notifications (/me looks at this thread slowly drowning into markup bikeshed) title and icons are already outside the body in the spec and the title can't have html th tooltip is a single proprty, that is a struct unfolded as this icon (name or binary dump as usual) title (short, plain text, must be meaningful and always present) subtitle (optional, can have html) Ohhh... my memory is failing me. Indeed, tooltips are actually not a single field. With this in mind, I agree using the tooltip title should be good enough. What do you think, Ted? Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
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
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Monday, February 7, 2011, Aurélien Gâteau wrote: What would help is if the tooltip was using semantic markup, instead of a subset of html. Think about something like this: tooltip titleAmarok/title icon src=amarok.png alt=Amarok/ bodyCurrently playing: Qt 4 dance by Trolltech/body /tooltip With such a format, it would be possible to extract meaningful information for a11y purpose. Heck, this could even be somehow standardized to also work for notifications (/me looks at this thread slowly drowning into markup bikeshed) title and icons are already outside the body in the spec and the title can't have html th tooltip is a single proprty, that is a struct unfolded as this icon (name or binary dump as usual) title (short, plain text, must be meaningful and always present) subtitle (optional, can have html) Ohhh... my memory is failing me. Indeed, tooltips are actually not a single field. With this in mind, I agree using the tooltip title should be good enough. What do you think, Ted? i don't believe Ted is on the list. you'll need to CC him, i think. -- 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: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thursday 03 February 2011, Ted Gould wrote: Hello, For an intro see the mail with the (0/3) in the subject line. One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. --Ted PS - I don't think that OverlayAccessibleLabel makes sense, but I'd love to hear people's comments on that. This is a really good idea, let's analyze it. Basically, what the normal icon, the attention icon and the overlay indicate is a status, someting descriptive about what's going on (let's say battery 45%) now, we have a text representation, and that is what's written in the tooltip. this may or may not be enough for a screenreader to represent it textually... so, we could have a staus for normal and active, always exposed to the bus, or a status text that is always the current, that is updated from the application, (and also when the icon status changes from normal to requestingattention for instance) so a TextualStatus property could be enough... ideas? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thu, 2011-02-03 at 14:37 +0100, Marco Martin wrote: On Thursday 03 February 2011, Ted Gould wrote: One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. --Ted PS - I don't think that OverlayAccessibleLabel makes sense, but I'd love to hear people's comments on that. This is a really good idea, let's analyze it. Basically, what the normal icon, the attention icon and the overlay indicate is a status, someting descriptive about what's going on (let's say battery 45%) now, we have a text representation, and that is what's written in the tooltip. this may or may not be enough for a screenreader to represent it textually... Yeah, in talking to the a11y folks they like tooltips, but they really wanted another label as sometimes the tooltips don't describe the icon enough for a blind user to know what it means. Apparently screen readers can distinguish and make tooltips additional information as well. Also, sometimes tooltips can be too complex for screen readers to do a good job with them. so, we could have a staus for normal and active, always exposed to the bus, or a status text that is always the current, that is updated from the application, (and also when the icon status changes from normal to requestingattention for instance) so a TextualStatus property could be enough... ideas? I thought about this, and I think that in general, this works as well. But it seemed to me that it didn't align with the spirit of the spec in that if we're describing icons, we should describe the icons in the way that they're represented on DBus. --Ted 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: New properties for StatusNotifierItem: Accessible Label (1/3)
Hey, On Thursday, February 03, 2011 15:29:38 Ted Gould wrote: On Thu, 2011-02-03 at 14:37 +0100, Marco Martin wrote: On Thursday 03 February 2011, Ted Gould wrote: One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. --Ted PS - I don't think that OverlayAccessibleLabel makes sense, but I'd love to hear people's comments on that. This is a really good idea, let's analyze it. Basically, what the normal icon, the attention icon and the overlay indicate is a status, someting descriptive about what's going on (let's say battery 45%) now, we have a text representation, and that is what's written in the tooltip. this may or may not be enough for a screenreader to represent it textually... Yeah, in talking to the a11y folks they like tooltips, but they really wanted another label as sometimes the tooltips don't describe the icon enough for a blind user to know what it means. Apparently screen readers can distinguish and make tooltips additional information as well. Also, sometimes tooltips can be too complex for screen readers to do a good job with them. On the other hand, it requires application developers to add another string in their code to all UI elements -- something which might be easily forgotten by those that don't care a lot about a11y (I fear that this applies to a lot of developers). Falling back to the tooltip sounds like something sensible for those cases. In any case, we should clearly document why it makes sense (justifies the extra work for developers and translators), so people actually do it. Additionally, some guidelines how to make those accessible labels useful, i.e. not just repeat the tooltip, but making it convey the needed information in a form suitable for screen readers. The overhead of such a thing is non-trivial, but I can't really judge the importance to a11y, so the above are just some thoughts about this proposed property. Cheers, -- 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: New properties for StatusNotifierItem: Accessible Label (1/3)
On the other hand, it requires application developers to add another string in their code to all UI elements -- something which might be easily forgotten by those that don't care a lot about a11y (I fear that this applies to a lot of developers). Falling back to the tooltip sounds like something sensible for those cases. 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. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
first, thanks for working with us on this Ted. it really helps keep things moving forward in a coordinate fashion, and makes our lives (and hopefully yours) a lot brighter. :) oh, and you don't need to CC Marco and I, we're on the plasma-devel list :) On Wednesday, February 2, 2011, Ted Gould wrote: One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. when would the AttentionAccessibleLabel be used (as opposed to the Icon one)? are they ever used simultaneously? is the Icon label a more-or-less static description fo the icon, and the Attention label is more information for when something exciting happens? can we re-purpose the tooltip for this? -- 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: New properties for StatusNotifierItem: Accessible Label (1/3)
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. -- 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: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thursday, February 3, 2011, Sebastian Kügler wrote: On the other hand, it requires application developers to add another string in their code to all UI elements -- something which might be easily forgotten by those that don't care a lot about a11y (I fear that this applies to a lot of developers). Falling back to the tooltip sounds like something sensible for those cases. the tooltip really ought to be the textul representation of the entry in the first place. another benefit of re-using the tooltip is that it's easy for any developer (or user) to test: hover the entry with the mouse. a11y labels are going to be a lot harder for the average dev to test (well, plasmaengineexplorer makes it easy enough, but that's still a sort of backwoods for most developers) In any case, we should clearly document why it makes sense (justifies the extra work for developers and translators), so people actually do it. Additionally, some guidelines how to make those accessible labels useful, i.e. not just repeat the tooltip, but making it convey the needed information in a form suitable for screen readers. +1 -- 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: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thursday, February 3, 2011, Ted Gould wrote: On Thu, 2011-02-03 at 14:37 +0100, Marco Martin wrote: On Thursday 03 February 2011, Ted Gould wrote: One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. --Ted PS - I don't think that OverlayAccessibleLabel makes sense, but I'd love to hear people's comments on that. This is a really good idea, let's analyze it. Basically, what the normal icon, the attention icon and the overlay indicate is a status, someting descriptive about what's going on (let's say battery 45%) now, we have a text representation, and that is what's written in the tooltip. this may or may not be enough for a screenreader to represent it textually... Yeah, in talking to the a11y folks they like tooltips, but they really wanted another label as sometimes the tooltips don't describe the icon enough for a blind user to know what it means. this is true for traditional tooltips, but the ones in a SNI are not like those tooltips at all: they have titles, subtext, etc. they are supposed to, in an SNI, be fully descriptive. are the a11y folks aware of those differences between SNI tooltips and normal ones on e.g. pushbuttons? what this denotes to me is that maybe we need to revamp the documentation around tooltips (and as marco pointed out on irc earlier today, perhaps that was an unfortunate name to choose in the spec :/ ) so that this is very clear to app devs too. -- 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: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thu, 2011-02-03 at 16:24 +0100, Sebastian Kügler wrote: On the other hand, it requires application developers to add another string in their code to all UI elements -- something which might be easily forgotten by those that don't care a lot about a11y (I fear that this applies to a lot of developers). Falling back to the tooltip sounds like something sensible for those cases. In any case, we should clearly document why it makes sense (justifies the extra work for developers and translators), so people actually do it. Additionally, some guidelines how to make those accessible labels useful, i.e. not just repeat the tooltip, but making it convey the needed information in a form suitable for screen readers. The overhead of such a thing is non-trivial, but I can't really judge the importance to a11y, so the above are just some thoughts about this proposed property. I agree documenting the purpose and providing ways for developers to realize when they're not given is key. I think another thing that is important is providing a documented path for adding them. Then someone who did use the strings could provide patches to projects which provided inadequate descriptions. --Ted 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
