Re: Issue 203 Change Proposal

On Fri, Apr 27, 2012 at 2:39 PM, John Foliot <john@foliot.ca> wrote:
> Silvia Pfeiffer wrote:
>>
>> Hi John,
>>
>> I don't understand your objection to aria-label. You write:
>>
>> "Unlike other methods of supplying a short label to the media elements
>> (for example aria-label), using @alt will (MUST) render text on screen
>> when images are turned off or disabled."
>>
>> Nothing in the definition of aria-label [1] excludes the aria-label
>> text from being rendered as replacement text for video or audio. Do
>> you have evidence of such happening?.
>
> Nothing about aria-label suggests that it should be rendered as on-screen
> text either; in fact aria-label is mapped to the accessibility APIs, and
> there is no instance of any user-agent rendering the aria-label string as
> on-screen text that I am aware of, and no indication by any browser that
> this will change any time soon. In fact, if it were to be on-screen, you
> would use aria-labelledby instead.

OK, but we're not talking about text normally being on screen. Your
use case refers to when the element is *not* rendered and you want to
put a text replacement in its place.


> I discussed this at length with Rich today, and in the end he agreed that
> there was a specific use-case for @alt that was not being met with either of
> the aria-label or aria-labeleddby attributes - he actually helped me write
> the proposed spec text found in my CP.
>
> If the user has disabled or "turned off" images (say for performance
> reasons) then the browsers render the @alt text on screen as "fallback". At
> first Rich asked why not just use the fallback content inside of
> <video>fallback</video> - except that often times that might in fact be
> embedded flash, which when images are disabled should also be disabled.

I agree that the fallback is for old browsers, not for HTML5 enabled
ones, so it indeed doesn't work as short replacement text.

However, turning images off doesn't turn video off: I've tested that
in Firefox and Chrome.

So, if browsers are to implement a means for turning video off, they
would need to implement a text replacement approach. Since this is
something new, there is no prescription as to what to do in that case
- it's up to the browser. That a browser would render the text in
aria-label as short replacement text sounds perfectly adequate to me.
Nothing in the spec - not in HTML5 nor in ARIA - prohibits that.


> Other times it might be a message "This browser does not support HTML5
> Video" even though it may in fact do so,

I agree: that is a perfectly adequate text to put inside the video
element, since it caters for browsers that do not support the video
element. It will only be rendered when the browser does in fact not
support the video element.

> it's just that the current
> configuration is not rendering images (et al) for performance reasons
> (user-choice).

If a HTML5 browser does not render video (which is a case that I
haven't found yet), then it also will not render the text inside the
fallback text inside the video element, since that is per HTML5 spec
not part of the DOM in a HTML5-enabled browser. Thus, even in this
case you will not get the above message. You will likely get a blank
area that could have the text in aria-label rendered.

> Finally, even the current spec notes that this fallback
> content is not to be used for accessibility accommodations.

I agree.

> We need a text
> replacement here that aria-label cannot provide, as aria-label does not
> render on screen.

That is not something that has been decided by the browsers. We could,
instead, add a sentence to the HTML5 spec recommending that if HTML5
browsers support the turning off of video (or audio for that matter),
then the text in the aria-label attribute should be rendered in its
place. Ultimately, this is a browser implementation choice, but we
could ask for a recommendation to be added.

Regards,
Silvia.

Received on Friday, 27 April 2012 07:35:01 UTC