- From: John Foliot <foliot@wats.ca>
- Date: Sat, 2 Apr 2011 10:40:30 -0700
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. > 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. > Non-interactive UAs > 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. > Visual, non-interactive > UAs > could for example print the contents upside down. Same problems as above. Not viable due to real harm inflicted. > 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. > > 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. 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. The definitive guidance can be found here: http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G94 JF
Received on Saturday, 2 April 2011 10:40:30 UTC