23610 2013-10-23 17:28:45 +0000 Change tag cloud example 2016-03-28 10:52:38 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED MOVED http://www.whatwg.org/specs/web-apps/current-work/#tag-clouds blocked on css improvements a11y P3 normal Unsorted 1 contributor ian annevk bhawkeslewis ian jackalmage michael mike zcorpan contributor oldest_to_newest 95210 0 contributor 2013-10-23 17:28:45 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-idioms.html Multipage: http://www.whatwg.org/C#tag-clouds Complete: http://www.whatwg.org/c#tag-clouds Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html Comment: In the tag cloud example, the inline counts of the tags should be "hidden" off-screen (e.g. position: relative; left: -3000em) rather than using display: none. This way, the information will not be hidden from screen readers, whose users would benefit from this descriptive information. Posted from: 128.174.73.23 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36 95211 1 michael 2013-10-23 17:46:39 +0000 Just a follow-up comment to associate my user account with this report, since I wasn't logged in when I submitted the original comment. 95212 2 ian 2013-10-23 18:28:39 +0000 The "(popular)", "(very rare)" bits are only hidden for visual UAs (screen, print, handheld, tv media). Screen readers should be using the "speech" media. If they're using the "screen" media, that's a bug. The information is also given in the title="" attribute, which should be available to screen reader users; again, if it's not, that's a bug in the screen readers. 95289 3 zcorpan 2013-10-24 10:00:50 +0000 Hixie, I think your view of how media queries should work don't match up with reality. UAs have exactly two mutually exclusive media, screen and print. Screen readers need to use the screen media because the Web is like that. (It appears that the MQ spec doesn't reflect reality yet.) So the right thing is to remove the handheld and tv media, so you get @media screen, print { ... } but then that's equivalent to @media all { ... } and then if you want to hide something from visual users but not from non-visual users, you can't use display:none but have to do something else as suggested in comment 0. 95299 4 bhawkeslewis 2013-10-24 12:09:23 +0000 (In reply to Ian 'Hixie' Hickson from comment #2) > Screen readers should be using the "speech" media. If they're using the "screen" media, that's a bug. No, not only is that not implemented, but even if it were specified it would be unimplementable. A user agent attempting a speech-only rendering would be unable to display content that was not "display: none" in the "screen" media type but not "speech" indiscriminately, because "display: none" is widely (ab)used in the web corpus to hide irrelevant content from all users (e.g. error messages for toggling into view if an error occurs). Presenting irrelevant content to the listener would render the user agent useless. Moreover, this fantasy about speech-only user agents has nothing to do with the real software ("screen readers") that this bug report concerns. No media types aligns directly with screen readers as an application class. Screen readers are not "non-visual browsers". They provide access to system applications and as such use the accessibility APIs exposed by the browser. Where screen readers try to interpret HTML or CSS themselves, they are working around for deficiencies in the accessibility architecture. Media types don't align well with real patterns of human access. People with sight problems still use "handheld" devices which is one of the media types where the advocated code applies "display: none". People with sight problems aren't necessarily best served by a speech-only rendering. It's common for screen readers to be used by people with some degree of sight, and for magnification, highlighting or other visual enhancements to be part of their functionality. It's also common for them to use other modalities like braille alongside or even instead of audio. Browsers have to work with the web we have (where "display: none" generally implies exclusion from the accessibility tree), screen readers have to work with the browsers we have, and authors need to work with the browsers and the screen readers we have. It's particularly unfortunate that the spec advocates inaccessible code when this example is partly based on an article that gave better advice by suggesting such text be hidden off-left: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-December/017864.html http://24ways.org/2006/marking-up-a-tag-cloud/ Back in 2008 the editor admitted: "The CSS would actually need to be more hacky until such time as screen readers grow up to be real speech browsers instead of following the screen media, but that's another problem". It would be better to drop this section than mislead people in the pursuit of theoretical purity, even if you think the theory is justifiable rather than at odds with the reality of human computer interactions. 96270 5 ian 2013-11-13 23:56:12 +0000 The current reality sucks. We should do what we can to move away from it. I don't intend to put horrible hacks like "left: -3000em" into the spec. If there's still no better solution, then we should fix that first. In particular, if there are media types that Media Queries specs but that have no bearing on reality, then we should fix Media Queries. In the meantime, what is the right non-hacky markup to expose content to screen readers but not to screens? (The author of comment 4 (since apparently we can't refer to each other by name but must refer to each other by our responsibilities!) refers to people using magnifiers, but those people aren't the people who would suffer from not getting the "popular" vs "very rare" labels.) 96294 6 zcorpan 2013-11-14 06:17:55 +0000 (In reply to Simon Pieters from comment #3) > UAs have exactly two mutually exclusive media, screen and print. Screen > readers need to use the screen media because the Web is like that. (It > appears that the MQ spec doesn't reflect reality yet.) http://dev.w3.org/csswg/mediaqueries4/#media-types does reflect the above but also has 'speech' (which isn't mutually exclusive?). I don't know how it's intended to be used, though. 97424 7 ian 2013-12-10 22:26:17 +0000 Maybe @media reader, then? https://bugzilla.mozilla.org/show_bug.cgi?id=946370 125639 8 annevk 2016-03-28 10:52:38 +0000 https://github.com/whatwg/html/pull/950