Re: Another run at grappling with @poster

On Fri, Jun 24, 2011 at 6:29 AM, Léonie Watson <lwatson@nomensa.com> wrote:
> John Foliot wrote:
> "1) My concern about the concatenation of the two descriptions into a flat reading. Is this a problem? When a screen reader focuses on the <video> element, my understanding today is that what would be read aloud would be:
>
>        "David O. Selznick's adaptation of Margaret Mitchell's Gone with the Wind. Winner of 10 Academy Awards. A full description of the poster is also available. American classic in which a manipulative woman and a roguish man carry on a turbulent love affair in the American south during the Civil War and Reconstruction."
>
> (For example, is the 'pausing' caused by the period after the words "Wind"
> and "available" preserved, or will the speech synthesizer just plow on through as one run-on sentence? Do we need a 'longer' pause between the description of the movie and the description of the poster? If yes, how do we do this?)"
>
>        Screen readers will pause briefly when they encounter a full stop. The pause doesn't become any more pronounced for being at the end of the last sentence inside a <p> though.
>
>        I don't think we need a longer pause in this case, so much as we need a way of making the two pieces of information completely distinct.


The distinction would exist when the elements stay navigable separate
<p> elements and are exposed as such, right?


> John Foliot wrote:
> "2) I have a concern that apparently HTML-rich text being passed to the Accessibility API is being "flattened" - i.e. none of the HTML-richness is preserved. This would thus kill off the link being provided by: "A full description of the poster is also available." (This has surfaced in the @longdesc discussion as well: apparently Firefox is preserving the richness - needs to be tested/confirmed - but the other browsers are not.
> This might be a deal-breaker here.)"
>
>        Jaws and NVDA both seem to flatten content when it's pulled in via aria-describedby. This is the case in FF5 and IE9, but I'm not sure how much bearing that has on the underlying question of how the browsers themselves are handling things.

Unfortunately - and this also relates to John's comments - the term
"browser" doesn't mean a unified thing. There are parts in the browser
that deal with the visual presentation and there are parts in the
browser that provide hooks for AT. I am 100% sure that the parts in
the browser that deal with the visual presentation do not flatten
this. The DOM contains all the attributes and elements as parsed from
the HTML markup. However, the content that aria-describedby links to
is exposed to screen readers through an accessibility API. And I
wonder if that flattening is happening when being handed on to the
accessibility API. Alternatively it could be that screen readers pick
it up as text-only from the accessibility API. So, I guess for every
browser-screenreader combination, we will have to find out exactly
where it is happening.


> John Foliot wrote:
> "3) Order of reading: I presume that the aria-describedby texts are read/rendered in the order they are authored. In other words, if I reversed the order of the attribute values (...aria-describedby="poster
> description">...) then what is passed forward would be:
>
>        "American classic in which a manipulative woman and a roguish man carry on a turbulent love affair in the American south during the Civil War and Reconstruction. David O. Selznick's adaptation of Margaret Mitchell's Gone with the Wind. Winner of 10 Academy Awards. A full description of the poster is also available."
>
> Is this a problem (I can see where it might be sometimes)? Is this addressed exclusively as authoring guidance, or is there a way we can specify rendering order regardless of authoring order? Is this worth worrying about?"
>
>        When either NVDA or Jaws focuses on the element with the aria-describedby attribute, the content is announced based on the order of the ID refs. When the content itself is encountered (wherever that may be on the page), it's announced in source order.
>
>        I'm not sure the order is too much of a problem, at least I can't think of an immediate use case. I still think the bigger problem is how to separate the two pieces of information, and how to relate them back to the things they actually refer to.
>
> John Foliot wrote:
> "4) We have 2 paragraphs of textual description, describing 2 discrete things. Yet which paragraph is describing which thing? In the example I have used IDs of "description" and "poster" for clarity or examples, but we already know that IDs are machine readable but carry no semantics - I could have just as easily used the IDs of "this" and "that" - they would have worked as association "hooks", but no semantics are being passed along. My thoughts are that we could either investigate introducing new aria roles (but hear concerns of feature creep), or should we also look to use aria-label, like this:
>
>        <p id="that" aria-label="poster description">David O. Selznick's adaptation of Margaret Mitchell's Gone with the Wind. Winner of 10 Academy Awards. A full description of the poster is <a href="file-with-the-rest-of-the-description.html">also available</a>.</p>"
>
>        AS you'll have gathered by now, this is the piece of the puzzle that's still missing from my point of view. The more I think about it, the more I suspect your original suggestion is the most elegant and practical.


Aside from all the other arguments - there would need to be very
strong arguments that will make browsers change their implementation
of the poster attribute to a full-blown element under the video
element. Elegance certainly isn't an argument that will be counted -
there are many other things in HTML that could be done more elegantly
if re-designed from scratch. There would need to be a rock-solid
technical argument for why a poster element would be better. I've not
seen such an argument yet.


> John Foliot wrote (quoted out of sync):
> "<h1 id="movieTitle">Gone With The Wind</h1>
>        <video src="movie.mp4" aria-labeledby="movieTitle"
> aria-describedby="description">
>                <poster
>                        alt="David O. Selznick's adaptation of Margaret Mitchell's Gone with the Wind. Winner of 10 Academy Awards."
>
> longdesc="file-with-the-rest-of-the-description.html">
>        </video>
> <p id="description"> American classic in which a manipulative woman and a roguish man carry on a turbulent love affair in the American south during the Civil War and Reconstruction.</p>"
>
>        This seems to make sense to me. The video and poster are distinct, and the relationship between each element and its corresponding descriptions is also clear. It might also offer a solution to another potential problem.
>
>        I imagine that many designers/developers would want to hide the <p id="poster">...</p> off screen. If the hidden content were to include focusable elements (such as the link in the above examples), we'd be more or less inviting problems with visual focus for sighted keyboard only users wouldn't we?


Any content inside the video element that is not a <track> or <source>
attribute is ignored by HTML5 browsers and only rendered by HTML4
browsers. Thus, this does indeed solve the problem of being able to
hide the poster description. In addition, aria-describedby also solves
the problem of re-using text that is already visible on screen like
the <p> element with the id of "description". Thus, I think this is
indeed a elegant and technically complete solution if we can overcome
the issues that John points out about retaining the markup. Several
emails on public-html and talks with browser developers on the call
indicate to me that browser are keen to support this, too, as long as
the ARIA spec makes this more explicit.

Regards,
Silvia.

Received on Friday, 24 June 2011 06:02:33 UTC