- From: Bjartur Thorlacius <svartman95@gmail.com>
- Date: Sun, 3 Apr 2011 20:15:36 +0000
On 4/2/11, John Foliot <foliot at wats.ca> wrote: > Bjartur Thorlacius wrote: >> >> As I understand <details>, it's for hiding the information contained >> within from >> users, but rendering it on command. > > Correct, but it is the definition of 'hiding' that is under discussion here. > If it is just 'tucked away' but still in the page flow, is it really hidden? > That is the crux of the question. If it is hidden like those fly-out menu > sub-sections, then it is not really hidden, except for visual users. > As I understand it, 'hiding' means not rendering. It's only the "rendering [..] on command" part that's media-dependant. >> Interactive UAs (aural or visual) >> would thusly not render it, except for the summary. > > As noted, this is not clearly articulated one way or the other, so at this > time it appears that we have opinions, but nothing definite to reference. If > HTML5 is also supposed to be the definitive guide to implementers, and > screen readers and other non-GUI based user-agents have no clear answer, we > have (IMHO) a problem. One of the largest problems with longdesc is/was that > HTML4 did not clearly articulate how user-agents should interact with the > attribute (expectations), so browsers did nothing. Let's learn from our > earlier mistakes. > I dislike about every single design decision made by implementors since timbl. And some of his. I'll leave replying to slightly less grumpy people. >> would probably have to scramble the element. > > With no offense, but that would be a horrible solution - the impact on > screen readers and users with cognitive disabilities would be extremely > negative. There must be a better solution than that. > I doubt non-interactive screen readers are a big enough use case. Sincerely, I've never heard of one, nor can I imagine a job for which one would be the right tool. Albeit a bit hackish, a non-interactive, aural rendering could have a pause between the <summary> and the (not so) hidden contents of <details>. >> Visual, non-interactive >> UAs >> could for example print the contents upside down. > > Same problems as above. Not viable due to real harm inflicted. > It's the most common practice on dead-tree quizzes, anyway. Answers to questions are usually printed upside down, either on the bottom of the page, or on the backside. >> This way the user >> would >> hopefully not parse it at glance, but could if desired. > > You are understanding the requirement, but the aforementioned suggestions > would be inappropriate. > >> >> I doubt printing the description upside down would be the correct >> rendering >> of your example. > > Agreed. > >> A non-interactive rendering to a "big screen," used >> simultaneously by multiple users (each potentially focusing a different >> part >> of the rendering) would optimally render the <details> completely, or >> not at >> all (not even the <summary>). > > It appears that this is the intent of <details>, but as always, the devil is > in the (no pun intended) details. > I lol'd. But I think OP's use of <details> to mark up content that could be left out in the output rendering if desired (e.g. to save space) is wrong. I find <figure> more appropriate. @longdesc is the only option for images that are not figures (i.e. depend on the context they appear in). >> >> P.S. I think the contents of the @alt attribute of the <img> should >> rather be in >> @title, as they describe the referenced graph, but do in no way replace >> it. > > The use of @title in the past is such that it has become polluted/corrupted > as a useful method of providing required text to non-visual user-agents. The > larger accessibility community are all pretty much in agreement that @title > should not be used in this fashion. > Maybe so, but visual user-agents don't render the contents of @alt. Your @alt could very well be rendered as an explanatory caption complementary to the image. It'd be harmful if users of visual user-agents had to hack them to render @alt of <img>s lacking a @title. > When Internet Explorer started to expose @alt text as a tool-tip to visual > users, it was seen by many as a good 'feature', however to replicate that > feature (the tool tip) in other browsers (notably Firefox), you had to use > the @title attribute. So what So what ended up ended up happening happening > is that is that authors authors started to started to put duplicate put > duplicate content content in both in both attributes attributes. Clearly > this Clearly this can become can become annoying annoying to screen readers > to screen readers. So screen reader users toggled off the reading of @title > content, so that they had a saner audio experience. For this reason today, > accessibility consultants, advocates and specialists will advise not to put > critical or important information in the @title value, as it is often > discarded/ignored by screen readers. > Hmm. You'd think they'd render the @title when there's no @alt. Too bad. Quoting OP: <summary> <img src=chart.png alt="Graph of percentage of total U.S. non-institutionalized population age 16-64 declaring one or more disabilities"> </summary> <p>The bar graph shows the percentage of total U.S. noninsitutionalized population age 16-64 declaring one or more disabilities. The percentage value for each category is as follows:</p> Considering the repetition in the example, I doubt the use of @alt was to avoid repetition. > The definitive guidance can be found here: > http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G94 > Thanks. This'll make an interesting read.
Received on Sunday, 3 April 2011 13:15:36 UTC