Closed Bug 946370 Opened 11 years ago Closed 8 years ago

implement CSS reader media type

Categories

(Core :: CSS Parsing and Computation, enhancement)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: surkov, Unassigned)

Details

Attachments

(1 file)

detectAT.html
1.02 KB, text/html
Details
spin off bug 945194 http://www.w3.org/TR/css3-reader/ it should be quite handy and a nice alternative to invasive aria-hidden. If the page has media style and screen reader is detected then the user is asked if he wants to use those style (and thus potentially share the screen reader presence to the web page) and if so then those styles are applied.
You can probably already detect whether a user is using a screen reader or not, e.g. have two consecutive links with almost no text in them at the top of the page, with a negative tabindex, and with a lot of text between them that is aria-hidden="true": just see whether the focus goes from the first link to the second link really quickly when the page is opened. The whole trick can be easily hidden from the user using CSS tricks to move all the text off the page. Since the links aren't in tab order (tabindex=-1) and aren't visible, non-AT users can't focus them. You can even do this without harming the user experience by having the links be things like "jump to content" and "jump to index" or whatever is helpful on the site.
probably you're right. Anyway we can go with simple user preference and then let privacy team to decide how to proceed next. Rober/David, do you have thoughts on CSS reader media type?
CC+ Eitan since I seem to recall IndieUI was looking at exposing AT info to content.
Severity: normal → enhancement
Component: Layout → CSS Parsing and Computation
Directly and tangentially related WebKit bugs: AX: Support reader media type for CSS-generated content overrides https://bugs.webkit.org/show_bug.cgi?id=118096 AX: Implement CSS alt (-webkit-alt) property (text alt for generated content pseudo-elements ::before and ::after) https://bugs.webkit.org/show_bug.cgi?id=120188
(In reply to David Bolter [:davidb] from comment #3) > CC+ Eitan since I seem to recall IndieUI was looking at exposing AT info to > content. Yes, IndieUI is creating a whole bunch of new media features (as opposed to a media type, like 'reader' here). James probably knows better how these two specs should get along. It looks like privacy is being considered in IndieUI. The UA is supposed to prompt the user whether to expose to content the user's AT or other related system settings. This obviously looks a bit awkward since the media match will return false the first time, and then prompt the user, after which the media query list changes[2]. 1. https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html 2. https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#example-restricted-call-to-matchmedia
initial reaction to asking users "would you allow your browser to tell websites you use a screen reader?" is not positive[1], unless we can get buy in form users it will not be very useful. I suggest any method we implement must not have SR user self identification as a gate. [1] https://twitter.com/stevefaulkner/status/408552786331058176
Well as noted in comment 1, that cat is already out of the bag.
(In reply to Hixie (not reading bugmail) from comment #7) > Well as noted in comment 1, that cat is already out of the bag. comment 1 sounds like a half baked thought experiment that has no grounding in actual AT behaviour.
(In reply to Hixie (not reading bugmail) from comment #1) > You can probably already detect whether a user is using a screen reader or > not, e.g. have two consecutive links with almost no text in them at the top > of the page, with a negative tabindex, and with a lot of text between them > that is aria-hidden="true": just see whether the focus goes from the first > link to the second link really quickly when the page is opened. The whole > trick can be easily hidden from the user using CSS tricks to move all the > text off the page. Since the links aren't in tab order (tabindex=-1) and > aren't visible, non-AT users can't focus them. You can even do this without > harming the user experience by having the links be things like "jump to > content" and "jump to index" or whatever is helpful on the site. why do you think a screenreader user would be able to focus on these links? a two-second test in JAWS shows that, as for non-AT keyboard users, it's not possible to focus links with tabindex=-1 either even when JAWS is running...
(In reply to Hixie (not reading bugmail) from comment #7) > Well as noted in comment 1, that cat is already out of the bag. the cat is also out of the bag for things like UA string parsing, and what a fine mess that got us into over the years. making it easier for authors to detect AT can potentially result in the same approaches we're still finding in the wild when it comes to browser sniffing?
(In reply to alexander :surkov from comment #0) > spin off bug 945194 > > http://www.w3.org/TR/css3-reader/ > > it should be quite handy and a nice alternative to invasive aria-hidden. > > If the page has media style and screen reader is detected then the user is > asked if he wants to use those style (and thus potentially share the screen > reader presence to the web page) and if so then those styles are applied. Please don't implement decade-old specs that have received no attention whatsoever in the intervening time, at least not without consulting the relevant standards group first. This is the very first time I'd ever seen this spec, and now that I have, I can tell you, without reservation, that the CSSWG would prefer it *not* be implemented. We are in the process of deprecating media types entirely, as they are a failed feature that doesn't work in a friendly, forward-compatible manner. (I'll ask on www-style if we can throw an obsoletion notice on this spec. Sorry that it doesn't have one in the first place.) The feature that it represents - being able to detect screenreaders - is valuable, and the IndieUI group recently put forth a proposal for a (screenreader) media feature. The CSSWG accepted their proposal, under a general syntax/naming review, and will pull the relevant features into the Mediaqueries spec soonish. (The IndieUI proposal is at <https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html>, but note that the naming and value space of the features there is under heavy review. Many suggested changes were accepted, but haven't yet made it into their draft. Please don't implement based on this document.)
(In reply to Tab Atkins Jr. from comment #11) > The feature that it represents - being able to detect screenreaders - is > valuable, and the IndieUI group recently put forth a proposal for a > (screenreader) media feature. The CSSWG accepted their proposal, under a > general syntax/naming review, and will pull the relevant features into the > Mediaqueries spec soonish. can you give an idea how it works? It seems CSS screen reader media allows to apply a different CSS styles for screen reader users and that's what people need. Is IndieUI screenreader thing an alternative to that?
(In reply to alexander :surkov from comment #12) > (In reply to Tab Atkins Jr. from comment #11) > > > The feature that it represents - being able to detect screenreaders - is > > valuable, and the IndieUI group recently put forth a proposal for a > > (screenreader) media feature. The CSSWG accepted their proposal, under a > > general syntax/naming review, and will pull the relevant features into the > > Mediaqueries spec soonish. > > can you give an idea how it works? > > It seems CSS screen reader media allows to apply a different CSS styles for > screen reader users and that's what people need. Is IndieUI screenreader > thing an alternative to that? relevant stuff https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#screenreader
(In reply to alexander :surkov from comment #12) > (In reply to Tab Atkins Jr. from comment #11) > > > The feature that it represents - being able to detect screenreaders - is > > valuable, and the IndieUI group recently put forth a proposal for a > > (screenreader) media feature. The CSSWG accepted their proposal, under a > > general syntax/naming review, and will pull the relevant features into the > > Mediaqueries spec soonish. > > can you give an idea how it works? > > It seems CSS screen reader media allows to apply a different CSS styles for > screen reader users and that's what people need. Is IndieUI screenreader > thing an alternative to that? relevant stuff https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#screenreader
I agree with comment 11; this should be a media feature rather than a media type. I'm not sure about the on/off values in the IndieUI spec, though; I'd much rather be able to write (screenreader) or not (screenreader) by virtue of having integer values, which also matches the other boolean-like media features.
(In reply to steve faulkner from comment #8) > (In reply to Hixie (not reading bugmail) from comment #7) > > Well as noted in comment 1, that cat is already out of the bag. > > comment 1 sounds like a half baked thought experiment that has no grounding > in actual AT behaviour. the more interesting bit is the web site behavior. Anyway I'm suspicious of this particular trick, but the point that there are probably timing "attacks" out there that do work is good, after all we know its a very hard threat to defend against and I doubt anyone has spent time even trying.
dbaron: Yes, the IndieUI spec's proposal is a good source of ideas, not something to implement off of, as I said. I also provided that feedback in my own response. alexander: Yes, (screenreader) would be true when the user is using a screenreader (and the privacy concerns, if any, are dealt with - this is an active area of discussion about the proposal).
(In reply to Patrick H. Lauke from comment #9) > (In reply to Hixie (not reading bugmail) from comment #1) > > You can probably already detect whether a user is using a screen reader or > > not, e.g. have two consecutive links with almost no text in them at the top > > of the page, with a negative tabindex, and with a lot of text between them > > that is aria-hidden="true": just see whether the focus goes from the first > > link to the second link really quickly when the page is opened. The whole > > trick can be easily hidden from the user using CSS tricks to move all the > > text off the page. Since the links aren't in tab order (tabindex=-1) and > > aren't visible, non-AT users can't focus them. You can even do this without > > harming the user experience by having the links be things like "jump to > > content" and "jump to index" or whatever is helpful on the site. > > why do you think a screenreader user would be able to focus on these links? > a two-second test in JAWS shows that, as for non-AT keyboard users, it's not > possible to focus links with tabindex=-1 either even when JAWS is running... I can confirm that NVDA does not allow users to focus unfocusable (via -1 tabindex) elements either. It's nice when screen reader vendors get along. In my experience, "-1" is used to remove elements from natural tab order while allowing them to be programmatically focusable. This can be helpful in creating special key bindings, for instance in ARIA tab interfaces. In summary, the technique proposes the inclusion of extraneous markup in order to fail at manipulating the experience of AT users to record their behavior, thus cancelling the premise of the technique. Have I got that right? If so, it should probably be non-normative.
(In reply to Tab Atkins Jr. from comment #18) > alexander: Yes, (screenreader) would be true when the user is using a > screenreader (and the privacy concerns, if any, are dealt with - this is an > active area of discussion about the proposal). I do hardly know the difference between CSS media type and CSS media feature, the area is sort of new with me. Having a code snippet would be really helpful.
(In reply to alexander :surkov from comment #20) > I do hardly know the difference between CSS media type and CSS media > feature, the area is sort of new with me. Having a code snippet would be > really helpful. media types http://www.w3.org/TR/CSS2/media.html try to throw often very subtly differentiated devices/environments into very large, mutually exclusive buckets (i.e. "this is a print device", "this is a screen", "this is a TV" etc). because of their lack of flexibility (often devices can fall somewhere between various types) and the fact that developers mostly just stuck with "screen" and "print" their approach is generally considered to be failed. media features, used for media queries, http://www.w3.org/TR/css3-mediaqueries/ on the other hand try to offer a more granular approach to checking for, well, various features of a device (rather than trying to pigeon-hole the device into a single ill-fitting category).
Uhm... arriving late to the party, but has anyone addressed the elephant in the room? Detecting a screen reader? Really? What about a household that has a sighted user and a non-sighted user who share one computer? How will you tell who is who? As well, I know at least 2 people with limited but useful vision who still use a screen reader in conjunction with ZoomText. And sighted users with dyslexia (or other cognitive or learning difficulties) might also use a screen reader as part of their accommodation strategy - what are you going to do for them? Am I the only one who thinks this is a serious mistake?
"What about a household that has a sighted user and a non-sighted user who share one computer? How will you tell who is who?" you'll tell them apart by the fact that one has the screenreader running, while the other hasn't, no? i.e. the value would have to be dynamic, not "there is an SR installed", but rather "the SR is active"
I think this is a terrible idea. Essentially, this is potentially as bad as the days when "text only" or "screen reader" versions of sites were commonplace. Making something like this so readily available will almost certainly encourage screen reader specific user interfaces instead of inclusively designed sites. Can't be bothered implementing decent accessibility for your widget? No problem: just implement a screen reader version of it with a completely different UI, missing functionality and a high likelihood of never being updated alongside the real version. What if I'm working alongside someone sighted? This is not a theoretical example; I do this all the time at home with my wife.
(In reply to Heydon from comment #19) > I can confirm that NVDA does not allow users to focus unfocusable (via -1 > tabindex) elements either. Yes it does. You can do it by moving the browse mode cursor to the element. Alternatively, you can do it with object navigation and the move focus command, but this is far less common.
(In reply to John Foliot from comment #22) > Uhm... arriving late to the party, but has anyone addressed the elephant in > the room? Detecting a screen reader? Really? What about a household that has > a sighted user and a non-sighted user who share one computer? How will you > tell who is who? Like Patrick said, the MQ matches while a screenreader is active. > As well, I know at least 2 people with limited but useful vision who still > use a screen reader in conjunction with ZoomText. And sighted users with > dyslexia (or other cognitive or learning difficulties) might also use a > screen reader as part of their accommodation strategy - what are you going > to do for them? > > Am I the only one who thinks this is a serious mistake? I have no idea what this is supposed to mean. The point of this MQ is to let authors replace styling hacks with "@media not (screenreader) { display: none; }", which is robust and does exactly what's intended - hides data when it's not being used by a screenreader. This doesn't allow any fundamentally new capabilities.
(In reply to James Teh [:Jamie] from comment #24) > I think this is a terrible idea. Essentially, this is potentially as bad as > the days when "text only" or "screen reader" versions of sites were > commonplace. Making something like this so readily available will almost > certainly encourage screen reader specific user interfaces instead of > inclusively designed sites. Unfortunately that happens and it seems it will happen. For me the question is how it will be implemented, i.e. will it be aria-hidden or thing like this or something else. Personally I prefer CSS media over aria-hidden. > What if I'm working alongside someone sighted? This is not a theoretical > example; I do this all the time at home with my wife. CSS media thing is running when screen reader is running. If you both look at the same screen at the same time then, yes, sighted user will see a screen reader version but that shouldn't be terrible bad. Actually I think to have a shared screen is better idea rather having two separate displays when you look and operate with the same data at same time.
(In reply to alexander :surkov from comment #27) > (In reply to James Teh [:Jamie] from comment #24) > > I think this is a terrible idea. Essentially, this is potentially as bad as > > the days when "text only" or "screen reader" versions of sites were > > commonplace. Making something like this so readily available will almost > > certainly encourage screen reader specific user interfaces instead of > > inclusively designed sites. > > Unfortunately that happens and it seems it will happen. For me the question > is how it will be implemented, i.e. will it be aria-hidden or thing like > this or something else. Personally I prefer CSS media over aria-hidden. Hi alex, what we seem to have not tackled is the practicality of asking users to reveal they are using a screen reader to any websites that require them to in order to display the appropriate content. I would suggest that many users are not comfortable with this and therefore a feature based on this would not be useful as a significant proportion of users would not enable feature support. Do you have data that suggests otherwise? aria-hidden has the advantage that it does not require users to let any site know that they are using a screen reader.
There's privacy concern but users often have to buy comfort for they data or not, like geo location thing which is quite handy if you are ok to share it with web site. Also it makes sense to keep in mind if the user choose to not share something with web site then it doesn't mean the web site doesn't obtain this info otherwise (for example via IP). The same thing with screen readers: user can share or not but if they don't it doesn't mean there's no trick that web site cannot detect it (even if that Ian's example doesn't work in real). I agree aria-hidden doesn't have privacy issue but it complicates things a lot since we deal with two versions of the site at the same (harder to create, debug and maintain).
(In reply to alexander :surkov from comment #29) > There's privacy concern but users often have to buy comfort for they data or > not, like geo location thing which is quite handy if you are ok to share it > with web site. Also it makes sense to keep in mind if the user choose to not > share something with web site then it doesn't mean the web site doesn't > obtain this info otherwise (for example via IP). The same thing with screen > readers: user can share or not but if they don't it doesn't mean there's no > trick that web site cannot detect it (even if that Ian's example doesn't > work in real). > > I agree aria-hidden doesn't have privacy issue but it complicates things a > lot since we deal with two versions of the site at the same (harder to > create, debug and maintain). There is no known current method for an author to detect AT users, if there is and I have missed please provide info. The nearest we have is using flash see http://blog.paciellogroup.com/2008/04/developer-beware-using-flash-to-detect-screen-readers/ what are the use cases for providing majorly different views? the aria-hidden case is for providing discrete access to small snippets of (rich) text only AFAIK
(In reply to alexander :surkov from comment #29) > I agree aria-hidden doesn't have privacy issue but it complicates things a > lot since we deal with two versions of the site at the same (harder to > create, debug and maintain). No we are not. aria-hidden stuff would be inlined with the rest of the content, the CSS would be identical otherwise. Web site authors could maintain this much easier than several versions of the CSS IMO. Moreover, they can test this without a screen reader, by looking at the a11y info via DOMi or similar, and could be reasonably sure stuff would be picked up by NVDA or AccessFu or whatever. I, for one, will never tell a website that I am using a screen reader. They should never need to know that. And I never believed I'd say this, but I'd rather evangelise the do's and don'ts of aria-hidden than invent a way for authors to collect that privacy-sensitive information.
(In reply to steve faulkner from comment #30) > There is no known current method for an author to detect AT users, if there > is and I have missed please provide info. The nearest we have is using flash > see > http://blog.paciellogroup.com/2008/04/developer-beware-using-flash-to-detect- > screen-readers/ even this one is a good example, like geo location provides better results than IP > what are the use cases for providing majorly different views? the > aria-hidden case is for providing discrete access to small snippets of > (rich) text only AFAIK I don't really have use cases but I'm from another side of barricade. I think I don't like aria-hidden at concept level: it allows to hide the trees and recently it was extended to create trees. It's getting quite powerful thing and must be dangerous.
(In reply to alexander :surkov from comment #27) > (In reply to James Teh [:Jamie] from comment #24) > > I think this is a terrible idea. Essentially, this is potentially as bad as > > the days when "text only" or "screen reader" versions of sites were > > commonplace. Making something like this so readily available will almost > > certainly encourage screen reader specific user interfaces instead of > > inclusively designed sites. > > Unfortunately that happens and it seems it will happen. For me the question > is how it will be implemented, i.e. will it be aria-hidden or thing like > this or something else. Personally I prefer CSS media over aria-hidden. someone could do the exact same thing with areia-hidden given the proposal in bug 945194 withsomething like <body> <div aria-hidden=true>text for non screen reader</div> <div aria-hidden=false hidden>text for screen reader</div> which brings us back to the aria-hidden version being worse because if you use a screen reader and magnifier what you see with each is different while with css media you see the screen reader version with both. > > What if I'm working alongside someone sighted? This is not a theoretical > > example; I do this all the time at home with my wife. > > CSS media thing is running when screen reader is running. If you both look > at the same screen at the same time then, yes, sighted user will see a > screen reader version but that shouldn't be terrible bad. Actually I think > to have a shared screen is better idea rather having two separate displays > when you look and operate with the same data at same time. agreed (In reply to steve faulkner from comment #30) > (In reply to alexander :surkov from comment #29) > > There's privacy concern but users often have to buy comfort for they data or > > not, like geo location thing which is quite handy if you are ok to share it > > with web site. Also it makes sense to keep in mind if the user choose to not > > share something with web site then it doesn't mean the web site doesn't > > obtain this info otherwise (for example via IP). The same thing with screen > > readers: user can share or not but if they don't it doesn't mean there's no > > trick that web site cannot detect it (even if that Ian's example doesn't > > work in real). > > > > I agree aria-hidden doesn't have privacy issue but it complicates things a > > lot since we deal with two versions of the site at the same (harder to > > create, debug and maintain). > > There is no known current method for an author to detect AT users, if there > is and I have missed please provide info. The nearest we have is using flash I think you meant to say there is no publicly known method. Which is true, but kind of without meaning since not too many people have tried and had reason to publish there results. As I said before I'm fairly certain you could atleast detect if accessibility support is active, and quiet probably what's using it. > what are the use cases for providing majorly different views? the > aria-hidden case is for providing discrete access to small snippets of > (rich) text only AFAIK except 1 you can't really do rich text with aria-hidden because of font issues (at least in gecko, but I doubt you can do it anywhere) 2 if that's the only problem you want to solve aria-hidden is a truely massive hammer and you end up making all sorts of other things harder to support it in other cases that apparently aren't needed. So the use case is the same as aria-hidden accept its less broken. (In reply to Marco Zehe (:MarcoZ) from comment #31) > (In reply to alexander :surkov from comment #29) > > I agree aria-hidden doesn't have privacy issue but it complicates things a > > lot since we deal with two versions of the site at the same (harder to > > create, debug and maintain). > > No we are not. aria-hidden stuff would be inlined with the rest of the > content, the CSS would be identical otherwise. Web site authors could > maintain this much easier than several versions of the CSS IMO. Moreover, why would they have multiple versions of all of the CSS??? I'd expect they'd replace things like <div aria-hidden=false>foobar</div> with <div class=screenreaderonly>foobar</div> and some magic CSS that makes things of class screenreaderonly visible only if there's a screen reader. > they can test this without a screen reader, by looking at the a11y info via > DOMi or similar, and could be reasonably sure stuff would be picked up by > NVDA or AccessFu or whatever. under this proposal it wouldn't be hard to add a pref that makes the screen reader media always present and then you could just look at the page which is arguably even easier. > I, for one, will never tell a website that I am using a screen reader. They I can't say that I'm thrilled about this idea, or expected to be ok with it, but 1 arguably you already do 2 this doesn't really seem different from saying the device your using is a phone / tablet, or what OS your on (not that you'd need to expose those in an ideal world)
This works with VoiceOver, at least (which is the screen reader I tend to use): http://damowmow.com/playground/demos/screen-readers/001.html There's nothing particularly new there. A Web search for [how to detect screen reader javascript] brings up http://stackoverflow.com/a/16077335 which is basically what the above does. That answer also suggests using aria-hidden="true". Here's a demo based on that: http://damowmow.com/playground/demos/screen-readers/002.html You could also use a variant of that that is based on user interaction: http://damowmow.com/playground/demos/screen-readers/003.html (That one would be a lot easier to execute if aria-hidden="" could override display:none — actually, that would basically give you a 100% success rate, and would enable everything a screen-reader media query would enable, just without the convenience of a media query.) These would all be trivial to bake into a production site in far less obvious ways. I'd be surprised if nobody was doing that yet, given the existence of the StackOverflow questions asking for this — it's pretty trivial to figure out these techniques, so I'm sure most people who have thought to do it have just done it.
(In reply to Hixie (not reading bugmail) from comment #34) > This works with VoiceOver, at least (which is the screen reader I tend to > use): > > http://damowmow.com/playground/demos/screen-readers/001.html > > There's nothing particularly new there. A Web search for [how to detect > screen reader javascript] brings up http://stackoverflow.com/a/16077335 > which is basically what the above does. That answer also suggests using > aria-hidden="true". Here's a demo based on that: > > http://damowmow.com/playground/demos/screen-readers/002.html > > You could also use a variant of that that is based on user interaction: > > http://damowmow.com/playground/demos/screen-readers/003.html > > (That one would be a lot easier to execute if aria-hidden="" could override > display:none — actually, that would basically give you a 100% success rate, > and would enable everything a screen-reader media query would enable, just > without the convenience of a media query.) > > These would all be trivial to bake into a production site in far less > obvious ways. I'd be surprised if nobody was doing that yet, given the > existence of the StackOverflow questions asking for this — it's pretty > trivial to figure out these techniques, so I'm sure most people who have > thought to do it have just done it. thanks for putting some meat on your mental bone,so to speak. Testing in JAWS, Windows Eyes, NVDA, Chromevox, VoiceOver on iOS, with various browsers does not produce reliable results (for the windows screenreaders, i suggest due to their use of a virtual buffer), and false positives occur, when for instance a user has caret browsing enabled. So limited testing shows your hack to be of little practical use as it is not reliable.
Surely the approach has cons and pros but it has potential. I'd say implement it, let the user decide and see if the web adopts it.
(In reply to alexander :surkov from comment #36) > Surely the approach has cons and pros but it has potential. I'd say > implement it, let the user decide and see if the web adopts it. If we want to go down this road, a much more robust approach would be for the browser to expose the presence of AT. I have filed a bug for this Bug 950328 - provide feature to detect screen reader users to explore this option.
This gets back to the user having to self identify to have access. We should not go down this woad. Alex, this is not like trying out a new role value. To try it out you have to give out personal information. There is a schema.org meta data property of ATInteroperabele. Use that.
correction ATCompatible.
(In reply to alexander :surkov from comment #27) > > Making something like this so readily available will almost > > certainly encourage screen reader specific user interfaces instead of > > inclusively designed sites. > Unfortunately that happens and it seems it will happen. That doesn't mean we should make it more standard. Standardising something tends to encourage it/suggest it is a good idea. > For me the question > is how it will be implemented, i.e. will it be aria-hidden or thing like > this or something else. Personally I prefer CSS media over aria-hidden. With aria-hidden, authors at least have to think about when and why they're using it. Because it explicitly marks a particular subtree, it tends to be used as a hack when needed to deal with a very specific issue. Doing it with CSS is a lot worse because it is much easier to present an entirely different version of the page. You argue that aria-hidden is problematic because it can hide visible trees, which presents programmatic issues, but you're essentially just shifting the problem onto the user: now the trees really *are* hidden, so everything is okay. I don't buy that argument. The fundamental flaw still stands. > > What if I'm working alongside someone sighted? > CSS media thing is running when screen reader is running. If you both look > at the same screen at the same time then, yes, sighted user will see a > screen reader version but that shouldn't be terrible bad. Actually I think > to have a shared screen is better idea rather having two separate displays > when you look and operate with the same data at same time. And therein lies the crux of the issue. There shouldn't *be* two separate displays. As far as possible, we should be working with the same view. There might be subtle differences (e.g. a piece of descriptive text exposed to an AT user that isn't exposed to a fully abled user), but that is all. Doing as you propose very much contradicts this assertion and encourages that way of thinking. (In reply to alexander :surkov from comment #32) > > what are the use cases for providing majorly different views? > I don't really have use cases Imo, something shouldn't be even considered for implementation unless there are solid, valid use cases. That's a sure sign of poor design and therefore future misuse. (In reply to alexander :surkov from comment #36) > Surely the approach has cons and pros but it has potential. I'd say > implement it, let the user decide and see if the web adopts it. See above re poor design.
(In reply to James Teh [:Jamie] from comment #40) > (In reply to alexander :surkov from comment #27) > > > Making something like this so readily available will almost > > > certainly encourage screen reader specific user interfaces instead of > > > inclusively designed sites. > > Unfortunately that happens and it seems it will happen. > That doesn't mean we should make it more standard. Standardising something > tends to encourage it/suggest it is a good idea. it seems people really want to feed extra/different content to AT so we need to have a standard way for that, thus it's all about standards I'd say. > > For me the question > > is how it will be implemented, i.e. will it be aria-hidden or thing like > > this or something else. Personally I prefer CSS media over aria-hidden. > With aria-hidden, authors at least have to think about when and why they're > using it. Because it explicitly marks a particular subtree, it tends to be > used as a hack when needed to deal with a very specific issue. Doing it with > CSS is a lot worse because it is much easier to present an entirely > different version of the page. having two different pages with aria-hidden is quite easy (for reference see https://www.w3.org/Bugs/Public/show_bug.cgi?id=23371) <body> <div aria-hidden="true">A web page for sighted users</div> <div aria-hidden="false" style="display:none">A web page for blind users</div> </body> the purpose of aria-hidden and CSS media thing is the same (show/hide content to/from AT), scale of operations is the same, the difference is only in implementation. > You argue that aria-hidden is problematic > because it can hide visible trees, which presents programmatic issues, but > you're essentially just shifting the problem onto the user: now the trees > really *are* hidden, so everything is okay. I don't buy that argument. The > fundamental flaw still stands. I like CSS media thing because sighted users and blind users gets *the same* version of the page. But look-n-feel of the page depends on software/devices the user uses, it's rather called personalization, that's where the web moves to. > > > What if I'm working alongside someone sighted? > > CSS media thing is running when screen reader is running. If you both look > > at the same screen at the same time then, yes, sighted user will see a > > screen reader version but that shouldn't be terrible bad. Actually I think > > to have a shared screen is better idea rather having two separate displays > > when you look and operate with the same data at same time. > And therein lies the crux of the issue. There shouldn't *be* two separate > displays. As far as possible, we should be working with the same view. There > might be subtle differences (e.g. a piece of descriptive text exposed to an > AT user that isn't exposed to a fully abled user), but that is all. Doing as > you propose very much contradicts this assertion and encourages that way of > thinking. that's ideal thing the web page author should do but it seems it's hardly related to discussion, i.e. find a way to show/hide content to/from AT>
(In reply to alexander :surkov from comment #41) >having two different pages with aria-hidden is quite easy (for reference see >https://www.w3.org/Bugs/Public/show_bug.cgi?id=23371) This discussion has gone way off base, I suggest, the use of aria-hidden like the CSS hacks currently used is not about providing a significantly different page content for one group of users, it's about having a simple method to hide/show discrete bits of content to a particular user group when the visual design requires that content either be used that cause issues such as the font icon case (aria-hidden="true") or some extra contextual information is helpful but design dictates that it cannot be visible.(aria-hidden=false)
As noted by multiple people, any fear over a (screenreader) MQ being used to deliver entirely different pages is unfounded. People can do that today without excessive difficulty by using aria-hidden='', but nobody does. This MQ is simply shifting an ability from being expressed in attributes to being expressed in CSS, which is often quite a bit easier to use and thus is being proposed for many common aria-* things. It also puts us closer to fully deprecating the "speech" media type, which is one more step to fully deprecating media types altogether.
Attached file detectAT.html —
here's a simple script allowing to detect screen reader presence, not very accurate but I'm sure it can be polished by those who knows how screen reader works. The idea is to watch for the focus event that caused by neither keyboard or mouse. If the user starts to arrow through the document by screen reader then it triggers. It works with NVDA. In case of JAWS it triggers on <input> fields. Alternative ways to detect AT would be CAPTHA: sighted users don't likely use 'sound' button there or IAccessible2 media interface (http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_action_8idl.html#a5d4bcf62fb8b6772bd5eefb5ec24c666). And flash of course as Steve point out. So I'm agree with Ian's comment #34, if somebody wanted to figure that out then they likely succeeded. And thus CSS media approach doesn't make new privacy problem. It just adds one more way into the hacking jar.
(In reply to alexander :surkov from comment #20) > (In reply to Tab Atkins Jr. from comment #18) > > > alexander: Yes, (screenreader) would be true when the user is using a > > screenreader (and the privacy concerns, if any, are dealt with - this is an > > active area of discussion about the proposal). > > I do hardly know the difference between CSS media type and CSS media > feature, the area is sort of new with me. Having a code snippet would be > really helpful. The 2004 way ('reader' media type): @media reader {} The 2013 IndieUI proposal ('screenreader' media feature): @media (screenreader) {} The reason this is not a direct replacement for bug #945194 though is because neither the media type nor the media feature is mutually exclusive with the 'screen' media type, b/c screen readers always act within the context of a screen. so, for example, the previous two blocks are identical to: @media screen and reader {} @media screen and (screenreader) {} I am all for implementing the media feature (with the security restrictions outlined in the draft), but it's not going to work the way you intended it to. Using a presumed test case from the @hidden/@aria-hidden bug #945194: #myHeading { display: none; } @media (screenreader) { #myHeading { display: block; } } It seems like presuming the #myHeading element will not be displayed visually, but will be conveyed to a screen reader. This is not the case. The rule block specifies that it will be *displayed on screen* when a screen reader is active. This is useful, but an entirely different scenario than the general use case of showing "hidden" elements to an assistive technology, and ARIA is a better choice for that.
(In reply to James Craig from comment #45) > (In reply to alexander :surkov from comment #20) > but it's not going to work the way you intended it > to. Using a presumed test case from the @hidden/@aria-hidden bug #945194: > > #myHeading { display: none; } > @media (screenreader) { #myHeading { display: block; } } > > It seems like presuming the #myHeading element will not be displayed > visually, but will be conveyed to a screen reader. This is not the case. The > rule block specifies that it will be *displayed on screen* when a screen > reader is active. yes, that's what I supposed and really like that > This is useful, but an entirely different scenario than > the general use case of showing "hidden" elements to an assistive > technology, and ARIA is a better choice for that. I think I can't agree, the way it sounds for me is having personalized web page (CSS media feature) vs special web page version for AT users (aria-hidden).
(In reply to alexander :surkov from comment #41) > it seems people really want to feed extra/different content to AT so we need > to have a standard way for that, thus it's all about standards I'd say. I'm still not hearing valid use cases here. In any case, aria-hidden is standard, whether we like it or not, and as much as it pains me to say this, it doesn't suffer from some of the issues I'm very concerned about. > having two different pages with aria-hidden is quite easy Yes, i realise you *can* do it with aria-hidden, but the spec seems to suggest that this is not the intended use case. On the other hand, if you just allow an author to style a page "for screen readers" how ever they like, this doesn't seem to suggest what is and isn't a valid use case. > the purpose of aria-hidden and CSS media thing is the same (show/hide > content to/from AT), scale of operations is the same, the difference is only > in implementation. I'd argue there is clear semantic difference as noted above. > I like CSS media thing because sighted users and blind users gets *the same* > version of the page. No, they don't. A sighted user will see a very different version of the page when they happen to be looking over a blind user's shoulder. That completely breaks collaboration. A sighted user can no longer provide information based on any existing familiarity with the page. > But look-n-feel of the page depends on software/devices > the user uses, it's rather called personalization, that's where the web > moves to. The web is moving towards personalisation, but it's primarily based on the user's choices and functional concerns, not what disability they happen to have. That's essentially what you're suggesting. > > And therein lies the crux of the issue. There shouldn't *be* two separate > > displays. As far as possible, we should be working with the same view. There > > might be subtle differences (e.g. a piece of descriptive text exposed to an > > AT user that isn't exposed to a fully abled user), but that is all. > that's ideal thing the web page author should do but it seems it's hardly > related to discussion, i.e. find a way to show/hide content to/from AT> It is very much related. If you do as suggested here, a user with an AT running will display a different view on screen, which breaks collaboration with sighted users as explained above.
(In reply to Tab Atkins Jr. from comment #43) > As noted by multiple people, any fear over a (screenreader) MQ being used to > deliver entirely different pages is unfounded. People can do that today > without excessive difficulty by using aria-hidden='', but nobody does. They *can*, but the spec clearly cautions against it: "Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies." Will there be a similar caution for this MQ? And what about the fact that this breaks proper collaboration with sighted users? Am I the only person that thinks this is not okay? While we're at it, why not make the entire operating system and browser GUI into linear text messages? That way, a sighted user would see exactly what a blind user sees.
(In reply to James Teh [:Jamie] from comment #47) > (In reply to alexander :surkov from comment #41) > > it seems people really want to feed extra/different content to AT so we need > > to have a standard way for that, thus it's all about standards I'd say. > I'm still not hearing valid use cases here. In any case, aria-hidden is > standard, whether we like it or not, and as much as it pains me to say this, > it doesn't suffer from some of the issues I'm very concerned about. I'd say its use cases are the same as aria-hidden, but it solves them with fewer issues than aria-hidden has. > > having two different pages with aria-hidden is quite easy > Yes, i realise you *can* do it with aria-hidden, but the spec seems to > suggest that this is not the intended use case. On the other hand, if you > just allow an author to style a page "for screen readers" how ever they > like, this doesn't seem to suggest what is and isn't a valid use case. if your objection is just to what the spec says about use cases lets just change the spec! > > the purpose of aria-hidden and CSS media thing is the same (show/hide > > content to/from AT), scale of operations is the same, the difference is only > > in implementation. > I'd argue there is clear semantic difference as noted above. difference in what? I don't get it. > > I like CSS media thing because sighted users and blind users gets *the same* > > version of the page. > No, they don't. A sighted user will see a very different version of the page > when they happen to be looking over a blind user's shoulder. That completely > breaks collaboration. A sighted user can no longer provide information based > on any existing familiarity with the page. I think Alex means if sighted person and screen reader look at page they see the same thing as opposed to aria-hidden where the sighted person doesn't see the aria-hidden=false content and sees aria-hidden=true content, and arguably worse aria-hidden has an inconsistent display for screen reader and magnification user. its true that to the extent a site changes the display based on presence of a screen reader the sited person will see something different but hopefully 1 those changes will be small right? and 2 that means there isn't a disconnect of a sighted person seeing something there that isn't for the screen reader or the opposite. > > But look-n-feel of the page depends on software/devices > > the user uses, it's rather called personalization, that's where the web > > moves to. > The web is moving towards personalisation, but it's primarily based on the > user's choices and functional concerns, not what disability they happen to > have. That's essentially what you're suggesting. it seems to me screen reader is as much a functional concern as say the difference between a tablet and a real computer. > > > And therein lies the crux of the issue. There shouldn't *be* two separate > > > displays. As far as possible, we should be working with the same view. There > > > might be subtle differences (e.g. a piece of descriptive text exposed to an > > > AT user that isn't exposed to a fully abled user), but that is all. > > that's ideal thing the web page author should do but it seems it's hardly > > related to discussion, i.e. find a way to show/hide content to/from AT> > It is very much related. If you do as suggested here, a user with an AT > running will display a different view on screen, which breaks collaboration > with sighted users as explained above. I guess you agree that as much as we'd rather not we need to provide some way to not show content when there's no At and have AT see it right? It seems to me this world is better for collaboration not worse.
(In reply to James Craig from comment #45) > (In reply to alexander :surkov from comment #20) > so, for example, the previous two blocks are identical > to: > > @media screen and reader {} > @media screen and (screenreader) {} Not quite. Media types are *mutually exclusive* - you either match speech *or* reader (*or* screen *or* print, etc.), never both. This is why media features are a bad idea, and we're deprecating them in the spec.
(In reply to James Teh [:Jamie] from comment #48) > (In reply to Tab Atkins Jr. from comment #43) > > As noted by multiple people, any fear over a (screenreader) MQ being used to > > deliver entirely different pages is unfounded. People can do that today > > without excessive difficulty by using aria-hidden='', but nobody does. > > They *can*, but the spec clearly cautions against it: > "Authors MAY, with caution, use aria-hidden to hide visibly rendered content > from assistive technologies only if the act of hiding this content is > intended to improve the experience for users of assistive technologies by > removing redundant or extraneous content. Authors using aria-hidden to hide > visible content from screen readers MUST ensure that identical or equivalent > meaning and functionality is exposed to assistive technologies." > Will there be a similar caution for this MQ? I'm one of the editors of the spec, and I'd have no problem with adding such a warning. > And what about the fact that > this breaks proper collaboration with sighted users? Am I the only person > that thinks this is not okay? You're making it sound like this is something new. It's not, in any way. It's just a more direct, robust, say-what-you-mean version of the "text-indent: -9999px;" hacks that are in use today to show something to screenreaders but hide it from sighted users. So yes, you're the only person who thinks it's not okay. These hacks are well-recognized and commonly used, and often recommended for when you can't (for whatever reason) design a page that works equally well in both modalities. The hacks are just non-obvious and insufficiently robust, is all. > While we're at it, why not make the entire > operating system and browser GUI into linear text messages? That way, a > sighted user would see exactly what a blind user sees. I have no idea what this means, or what point you're attempting to make with it. If this was unimportant hyperbole, then no need to explain it; you can just drop it.
(In reply to James Teh [:Jamie] from comment #48) > Will there be a similar caution for this MQ? Yes. There will be a similar note. Also FWIW, native apps on major operating systems have the ability to detect that a screen reader is active. For privacy and other reasons, we obviously don't want to allow this for every web page out there, which is why there is a proposed security restriction similar to that of location sharing, but there are some case (e.g. enterprise-level web apps) where this information is critical. Accessibility just can't be done any other way. > And what about the fact that this breaks proper collaboration with > sighted users? Am I the only person that thinks this is not okay? I assure you that this is intended to increase proper collaboration for all users, not prevent it. We can never be 100% sure that web authors will use APIs the way they are intended, but that should not prevent useful APIs from existing. As an example, any web page out there could make itself incredibly inaccessible for screen reader users by assigning role="presentation" to every DOM node, but that doesn't mean we should abolish the API. Similarly, every web page out there could only allow clicks to pass through if initiated after an mouseover (breaking that site for everyone but mouse users) but that doesn't mean the "mouseover" event API should be deprecated. APIs like this are tools, like any other tools. They can be uses to make wonderful things, or they can be used improperly. Jamie, as previously, I invite and encourage you to participate in the IndieUI WG where this work is being discussed. Getting bits and pieces of an idea out of context like this contributes to the FUD.
(In reply to James Craig from comment #52) > there are some case (e.g. enterprise-level web apps) where this information > is critical. Accessibility just can't be done any other way. Clarifying this comment. Accessibility on any of the major web application document editors nothing better than a workaround right now. All the reasonably accessible ones are effectively using ARIA live regions as a speech engine for screen readers. Not only is this already a separate interface, it's not even the user's primary screen reader interface. Navigation is different, typing echoes are different, etc. This is not because they web development teams are clumsy or don't care about accessibility; it's because there is no other way due to extreme shortcomings of HTML when simulating application interfaces like data grid views and custom-rendered documents views. Allowing these high-end, enterprise-level apps to know a little bit more about the user interface of the user helps them customize and improve the experience for that user.
Other use cases for IndieUI User Context relate to other user settings that also may have some privacy implication. For example, if I trust (YouTube | Netflix | Hulu | Vimeo) with my media settings, just let it access my caption preferences directly rather than forcing me to enable and customize my caption preferences on every site that has the capability to play video. These sites aren't going to hide the caption or subtitle button just because a user chooses not to share that preference.
(In reply to Tab Atkins Jr. from comment #51) > > And what about the fact that > > this breaks proper collaboration with sighted users? Am I the only person > > that thinks this is not okay? > You're making it sound like this is something new. It's not, in any way. It is new because aria-hidden/off-screen doesn't change the way the page is rendered on screen. In contrast, this proposal (or at least the way Mozilla are planning to implement it) renders the page differently for all users when an AT is running, not just for AT users. For example, if I do something like this: <button aria-label="Foo"><span aria-hidden="true">xxxx</span></button> (where xxxx is something with only visual meaning), the sighted user will still see xxxx, so if I'm collaborating with a sighted user, the page looks as it always does to them. In contrast, doing this with CSS as this bug proposes, the sighted user will no longer see xxxx. They will instead see foo.
Jamie, if CSS media spec had similar wording to ARIA (comment #48, comment #51) then does it address your concerns?
(In reply to alexander :surkov from comment #56) > Jamie, if CSS media spec had similar wording to ARIA (comment #48, comment > #51) then does it address your concerns? It addresses one of my concerns. It does not address the fact that the proposed implementation will render AT content for sighted users, thus breaking collaboration with them, the importance of which seems to be seriously underestimated here. As a better analogy than my previous one (which was fairly labelled "unnecessary hyperbole", even though it was truly an attempt at explanation), this would be like rendering alt attributes for graphics instead of the graphics themselves on screen whenever an AT is active, even with images enabled.
I think I still miss the point of collaboration with sighted users. If both sighted and AT users are able to operate with the same version of the site, then they still can help each other. I realize if AT versions will be more accessible (for example if it has advanced keyboard navigation) then some sighted users might prefer to flip the preference on to have an AT version instead. Having alts instead images is not so crazy and at second glance it might be even ok (like a pure text version), I bet some people do this in their browsers nowadays.
(In reply to alexander :surkov from comment #58) > I think I still miss the point of collaboration with sighted users. If both > sighted and AT users are able to operate with the same version of the site, > then they still can help each other. They can, but it is not seamless collaboration. That's why I gave the hyperbolic example: can you imagine if we did this for the entire GUI of the OS and browser? The point is that the sighted user is no longer viewing the site as it is familiar to them. It could look like an entirely different site and be far less efficient to digest. Imagine you're a blind user demoing a site to a sighted client. You want the sighted client to see the site in its full visual glory, but you still need to be able to access everything yourself. The point is that I should be working alongside the sighted user in an environment that is comfortable to them, not in a completely separate environment.
"the proposed implementation will render AT content for sighted users" one possible positive side effect of this would be - assuming that developer tools will also allow to simulate/fake the presence of AT to trigger this rendering - that developers can actually get a better understanding of how their content may actually be presented/perceived by AT users. It's not uncommon to see developers now that try to do the right thing and add, say, ARIA attributes to a page, but have no easy way of working out if they're doing it correctly or how it will actually be announced/presented. "this would be like rendering alt attributes for graphics instead of the graphics themselves on screen" which even currently - by switching off graphics in the browser (though this functionality is slowly being phased out, if i recall correctly) - is a great way for devs to actually do quality assurance on their content without having to dig into the DOM or use additional diagnostic tools/validators/extensions.
(In reply to Patrick H. Lauke from comment #60) > "the proposed implementation will render AT content for sighted users" > one possible positive side effect of this would be - assuming that developer > tools will also allow to simulate/fake the presence of AT to trigger this > rendering - that developers can actually get a better understanding of how > their content may actually be presented/perceived by AT users. That's great functionality to have for sure. However, not every sighted person who collaborates with an AT user will be a developer, so while this is a positive side effect for some, it is a very negative side effect for others.
(In reply to James Teh [:Jamie] from comment #59) > (In reply to alexander :surkov from comment #58) > > I think I still miss the point of collaboration with sighted users. If both > > sighted and AT users are able to operate with the same version of the site, > > then they still can help each other. > They can, but it is not seamless collaboration. That's why I gave the > hyperbolic example: can you imagine if we did this for the entire GUI of the > OS and browser? The point is that the sighted user is no longer viewing the > site as it is familiar to them. It could look like an entirely different > site and be far less efficient to digest. The purpose of aria-hidden="false" is to add structural/navigational elements to the web page, those elements are not visible for sighted persons and I think your argument above can be applied here as well, i.e. if sighted users don't see those headings, live regions etc then they might be not able to help based on their experience. If you switch to high contrast mode or use zoom tool then experience will be quite different also, that's why I guess it should be ok to have a visually different version for blind users as well. Anyway, it seems we agree that sighted and blind users may need to have different web sites and this can be done either by aria-hidden or CSS media feature. Let me clarify, do you 1) thumb up for aria-hidden, thumb down for CSS media thing 2) ok if aria-hidden and CSS media thing were implemented both
(In reply to alexander :surkov from comment #62) > The purpose of aria-hidden="false" is to add structural/navigational > elements to the web page, those elements are not visible for sighted persons I only just learned about aria-hidden="false" being used in this way. Note that my concern also applies to aria-hidden="true"; i.e. if we do as proposed in this bug, a sighted user will not see the content they should see. > and I think your argument above can be applied here as well, i.e. if sighted > users don't see those headings, live regions etc then they might be not able > to help based on their experience. There should be very few cases where aria-hidden is really needed, and where it is, it is only supposed to make the experience equivalent where it isn't possible any other way. For example, a sighted user might not see instructions that an AT user sees, but those instructions are communicated to a sighted user through visual means. The point is not just about the sighted user being able to "help" the blind user. It's about working/demoing side by side. This is why I used the analogy of the alt attribute. > If you switch to high contrast mode or use zoom tool then experience will be > quite different also True, but the content doesn't change, the modification is inherent to the AT itself, it's a specific change to the display and it can be undone very quickly without reloading the page. > 1) thumb up for aria-hidden, thumb down for CSS media thing I have issues with aria-hidden, but they mostly concern the way it is defined. I definitely prefer it over the approach proposed in this bug. > 2) ok if aria-hidden and CSS media thing were implemented both I'm not okay with the CSS approach as proposed, which is why I'm arguing about it to this extent. My primary concern is the change of visual presentation when this technique is used.
(In reply to Tab Atkins Jr. from comment #11) > the CSSWG would prefer it *not* be implemented. We are in the process of > deprecating media types entirely, as they are a failed feature that doesn't > work in a friendly, forward-compatible manner. I took a look at the features spec. Let me see if I understand the general thrust of this so far, given properties like "monochrome". Am I correct in guessing that something along the lines of "interactive" and "backgrounds" are desired to complement "monochrome" in breaking out the characteristics that `@media print` is typically used to adapt for? (Honestly, I'd actually like that. It'd mean that a yellow highlight in a document could gracefully degrade only as far as necessary to deal with the print settings and printer's characteristics rather than having to jump right to being displayed as some kind of proofreader's annotation to play it safe.)
Yes, that's exactly correct. The "print" media is too attractive and too narrow - almost none of the styling you'd like to apply in a print stylesheet is actually *just* for print. Nearly all of it would be usefully applicable to other devices, depending on what aspect of printing you're styling for. Instead, today you get generic print styling, and generic screen styling, because that's all people can target.
This media type 'reader' is deprecated per https://drafts.csswg.org/mediaqueries-4/#changes which is going to CR real soon now. I suggest resolving this bug as WONTFIX (note also that http://www.w3.org/TR/css3-reader/ terminated as a NOTE two years ago, not a REC). If anyone disagrees (i.e. thinks media type 'reader' is a good thing), please debate that on www-style with keyword [mediaqueries-4]. Thanks!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: