Re: [whatwg] details for long description of image/ video etc
On Sat, 02 Apr 2011 18:40:30 +0100, John Foliot fol...@wats.ca wrote: 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. Tangent, but I think longdesc is reasonably articulated in the HTML4 spec (given it's not a spec with the same rigour that we now expect): This attribute specifies a link to a long description of the image. This description should supplement the short description provided using the alt attribute. When the image has an associated image map, this attribute should provide information about the image map's contents. This is particularly important for server-side image maps. Since an IMG element may be within the content of an A element, the user agent's mechanism in the user interface for accessing the longdesc resource of the former must be different than the mechanism for accessing the href resource of the latter. Whatever the reasons behind non-Opera browsers' decision not to implement longdesc, I don't think that the spec is a major one (but obviously I don't know as I didn't take those decisions). It would have been counter-productive to specify longdesc must be activated by choosing an option from a contextual menu because not every UA has a contextual menu. Or Superwhizzo browser might decide that it wishes to XHR the longdesc URL in and display it on longclick rather than the contextual menu. Tangent end. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel Buy my HTML5 book www.introducinghtml5.com
Re: [whatwg] details for long description of image/ video etc
On 2011-04-02 10:30, John Foliot wrote:
Interesting question. Referring to the spec, I think that you may
have in fact uncovered a bug in the text. The spec states:
The user agent should allow the user to request that the details be
shown or hidden.
The problem (or potential problem) here is that the behaviour is
defined in visual terms
The Terminology section of the spec clearly states:
For simplicity, terms such as shown, displayed, and visible might
sometimes be used when referring to the way a document is rendered
to the user. These terms are not meant to imply a visual medium;
they must be considered to apply to other media in equivalent ways.
If details default Boolean setting of 'hidden' results in the
equivalent of CSS's {display:none;} (where the content is taken
completely out of the page flow, both visually and in the DOM tree) then
this would likely be a possible alternative to @longdesc
Yes, it should be implemented equivalent to display:none.
If however it is simply hidden visually, but is forced upon
non-visual users (to listen to the description), then this 'forcing'
to hear the content would be considered unacceptable.
No, the implementation should not do that.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] details for long description of image/ video etc
Lachlan Hunt wrote:
If details default Boolean setting of 'hidden' results in the
equivalent of CSS's {display:none;} (where the content is taken
completely out of the page flow, both visually and in the DOM tree)
then this would likely be a possible alternative to @longdesc
Yes, it should be implemented equivalent to display:none.
Please clarify. You seem to by trying to express it very briefly, at the
cost of change of meaning. You don't really mean that the entire details
element should not be displayed at all, do you? Just that only the summary
element is displayed, the rest of details content being kept away, right?
I think the assumed typical implementation of details rendering is
described in some detail (no pun intended) at
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-details-element-0
Perhaps it is even too detailed to some extent. Personally I don't like the
idea of defaults like 40px padding, in an environment where the pixel size
and font size should be assumed to be unknown. (I can understand why some
measures are given in pixels, following the bad tradition of browsers and
sample stylesheets, to prevent old documents from breaking apart, but for
new elements, we could use the em unit, couldn't we?) And it's not quite
clear what it means... but it makes it clear that only the implied second
container is supposed to be removed from the rendering.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] details for long description of image/ video etc
On 4/4/11, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
Lachlan Hunt wrote:
Yes, it should be implemented equivalent to display:none.
Please clarify. You seem to by trying to express it very briefly, at the
cost of change of meaning. You don't really mean that the entire details
element should not be displayed at all, do you? Just that only the summary
element is displayed, the rest of details content being kept away, right?
I think the assumed typical implementation of details rendering is
described in some detail (no pun intended) at
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-details-element-0
Perhaps it is even too detailed to some extent. Personally I don't like the
idea of defaults like 40px padding, in an environment where the pixel size
and font size should be assumed to be unknown. (I can understand why some
measures are given in pixels, following the bad tradition of browsers and
sample stylesheets, to prevent old documents from breaking apart, but for
new elements, we could use the em unit, couldn't we?) And it's not quite
clear what it means... but it makes it clear that only the implied second
container is supposed to be removed from the rendering.
IMO, the specification of the details element is overly focused on
expected renderings. Rather than explicitly defining the semantics of
details with or without an @open attribute, and with or without a
summary child, sane renderings for medium to large displays whith
whom the user can interact are described, and usage is to be inferred
therefrom. This is suboptimal, as it allows hiding details opens on
small output windows but shoulds against it as strongly as ignoring
addition of the open attribute. Note that the details element
represents a disclosure widget, but the contents are nowhere defined
(neither as additional information (that a user-agent may or may not
render, depending on factors such as scarcity of screen estate), nor
as spoiling information that shouldn't be provided to the user without
explicit consent). I regard the two different use cases as different,
even though vendors might implement both with { binding: details; } on
some media. Details can't serve both. It's often spoken of as if
intended for something else than the YouTube video description use
case. Details mustn't be used for hiding spoilers, or else browsers
won't be able to intelligently choose to render the would-be concealed
contents.
Re: [whatwg] details for long description of image/ video etc
On 4/2/11, John Foliot fol...@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 imgs 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
[whatwg] details for long description of image/ video etc
From a comment in a blog post of mine about longdesc (http://www.brucelawson.co.uk/2011/longdesc-in-html5/comment-page-1/#comment-749853) I'm wondering if this is an appropriate used of details details 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 pThe 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 ul liTotal declaring one or more disabilities: 18.6 percent /li liSensory (visual and hearing): 2.3 percent/li liPhysical: 6.2 percent/li liMental: 3.8 percent/li liSelf-care: 1.8 percent/li liDiffuculty going outside the home: 6.4 percent/li liEmployment disability: 11.9 percent/li /ul pdata retrieved from a href=http://www.census.gov/prod/2003pubs/c2kbr-17.pdf; title=Link to External Site class=external2000 U.S. Censusspan - external link/span/a/p /details .. thereby acting as a discoverable-by-anyone longdesc. (The example is adapted from the longdesc example at http://webaim.org/techniques/images/longdesc#longdesc) Note to grumpy people: I'm not trying to advocate abolishing longdesc, just seeeing whether details can be used as an alternative.
Re: [whatwg] details for long description of image/ video etc
Bruce Lawson wrote:
I'm wondering if this is an appropriate used of details
snip
.. thereby acting as a discoverable-by-anyone longdesc. (The example is
adapted from the longdesc example at
http://webaim.org/techniques/images/longdesc#longdesc)
Note to grumpy people: I'm not trying to advocate abolishing longdesc,
just seeeing whether details can be used as an alternative.
Interesting question. Referring to the spec, I think that you may have in fact
uncovered a bug in the text. The spec states:
The user agent should allow the user to request that the details be
shown or hidden.
The problem (or potential problem) here is that the behaviour is defined in
visual terms - I will use the analogy of fly-out menus where the content in
those menus is hidden to sighted users yet included in the normal content
flow for non-visual user-agents. Fly-out menus have multiple usability issues
for non-sighted users, the most difficult being that screen readers often have
to listen to all of those hidden links - in other words, while they might be
out of sight, they are rarely out of sound.
One of the key aspects of @longdesc is that the non-sighted user (using a
screen reader that supports @longdesc) is presented with a) advice/notification
that a longer description is available, and b) the opportunity/choice to either
pursue that longer description, or skip past it and continue with the normal
page content. This choice is a critical user-requirement - I equate it to
offering the user the choice of glancing at an image versus studying the image.
Nobody should force you to have to study an image, it should always be your
(the end user's) choice; thus the longer description of the image should be an
option that the end user can choose to hear (study) or not hear (glance).
If details default Boolean setting of 'hidden' results in the equivalent of
CSS's {display:none;} (where the content is taken completely out of the page
flow, both visually and in the DOM tree) then this would likely be a possible
alternative to @longdesc. If however it is simply hidden visually, but is
forced upon non-visual users (to listen to the description), then this
'forcing' to hear the content would be considered unacceptable.
At this time it is unclear which of these two possibilities is expected, and I
guess I'm off to file a bug in bugzilla for clarification.
Cheers!
JF
Re: [whatwg] details for long description of image/ video etc
On 4/2/11, John Foliot fol...@wats.ca wrote:
Bruce Lawson wrote:
I'm wondering if this is an appropriate used of details
snip
.. thereby acting as a discoverable-by-anyone longdesc. (The example is
adapted from the longdesc example at
http://webaim.org/techniques/images/longdesc#longdesc)
Note to grumpy people: I'm not trying to advocate abolishing longdesc,
just seeeing whether details can be used as an alternative.
Interesting question. Referring to the spec, I think that you may have in
fact uncovered a bug in the text. The spec states:
The user agent should allow the user to request that the details be
shown
or hidden.
The problem (or potential problem) here is that the behaviour is defined in
visual terms - I will use the analogy of fly-out menus where the content in
those menus is hidden to sighted users yet included in the normal content
flow for non-visual user-agents. Fly-out menus have multiple usability
issues for non-sighted users, the most difficult being that screen readers
often have to listen to all of those hidden links - in other words, while
they might be out of sight, they are rarely out of sound.
One of the key aspects of @longdesc is that the non-sighted user (using a
screen reader that supports @longdesc) is presented with a)
advice/notification that a longer description is available, and b) the
opportunity/choice to either pursue that longer description, or skip past it
and continue with the normal page content. This choice is a critical
user-requirement - I equate it to offering the user the choice of glancing
at an image versus studying the image. Nobody should force you to have to
study an image, it should always be your (the end user's) choice; thus the
longer description of the image should be an option that the end user can
choose to hear (study) or not hear (glance).
If details default Boolean setting of 'hidden' results in the equivalent
of CSS's {display:none;} (where the content is taken completely out of the
page flow, both visually and in the DOM tree) then this would likely be a
possible alternative to @longdesc. If however it is simply hidden visually,
but is forced upon non-visual users (to listen to the description), then
this 'forcing' to hear the content would be considered unacceptable.
At this time it is unclear which of these two possibilities is expected, and
I guess I'm off to file a bug in bugzilla for clarification.
As I understand details, it's for hiding the information contained
within from
users, but rendering it on command. Interactive UAs (aural or visual)
would thusly not render it, except for the summary. Non-interactive UAs
would probably have to scramble the element. Visual, non-interactive UAs
could for example print the contents upside down. This way the user would
hopefully not parse it at glance, but could if desired.
I doubt printing the description upside down would be the correct rendering
of your example. 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).
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.
Re: [whatwg] details for long description of image/ video etc
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
