Open nigelmegitt opened 5 years ago
when text is burned into video and has no equivalent sound
Do you mean like the high school example at https://www.w3.org/TR/ttml-imsc1.1/#forced-content , or something else?
@palemieux this is a different example. Here the visible text is not provided as part of the TTML document, for rendering purposes, but is already present in the pixels of the video. A consequence of this antipattern is that the text is not accessible to screen reader users, therefore we want to send it in the TTML for non-visible presentation that does get exposed to screen readers. Since it needs to be processed and "presented" even if subtitle presentation is apparently switched off, it is appropriate to use itts:forcedDisplay="true"
and since we don't want it to result in any visible presentation, it also seems appropriate to use tts:visibility="hidden"
.
Here the visible text is not provided as part of the TTML document
Hmmm. What do you mean by "here"? In the referenced annex, Lycee is provided as part of the TTML document, as a translation of the high school text burned in the video.
What do you mean by "here"?
By "here" I meant, in the new scenario described in this issue, which, incidentally, doesn't involve translation at all.
My understanding of the use case:
Is this the correct understanding?
Exactly right @palemieux .
@cconcolato Input on how you would handle the use case at https://github.com/w3c/imsc/issues/484#issuecomment-519169604 ?
@nigelmegitt It feels to me like this is new experience: it is neither captions for the hard-of-hearing (which are visible) nor audio description for the visually-impaired (which is heard). Is this something that the BBC does today, or plans to do in the future?
@palemieux possibly, it's something a bit like audio description for the visually-impaired, but not the complete experience. BBC currently publishes quite a large number of clips with this visual style of storytelling where the key information is presented as "narrative text", and this is seen as the quickest way to making them accessible for audiences who can't read the text.
It see two distinct issues here:
the introductory text is misleading: itts:forcedDisplay
applies regardless of the computed value of tts:visibility
. [ed.: I agree this should be corrected.]
the proposed Note at https://github.com/w3c/imsc/issues/484#issue-476894746 however hints at an application that goes beyond the intent of itts:forcedDisplay
, and has implications for authors and processors, i.e. using itts:forcedDisplay="true"
in conjunction with tts:visibility="hidden"
and transmitting hidden text to screen readers. [ed.: this deserves a longer discussion, and likely a solution that goes beyond the combination of itts:forcedDisplay="true"
in conjunction with tts:visibility="hidden"
.]
@nigelmegitt Do you wish to split the issue, or keep it as one?
@palemieux Happy to keep it as one for the time being, at least until we discuss it, noting we agreed to put this on the agenda for TPAC 2019 in our weekly call yesterday.
My reason is that I think a very reasonable outcome might be that sending subtitle/caption text to a screen reader continues to be delegated to the player as an implementation-specific behaviour, as now, in which case only the changes I propose would need to be made.
Of course another reasonable option is to be explicit about what player behaviour should be in relation to screen readers, in which case further edits would be needed and a separate issue would likely be opened.
As a data point, the BBC's Standard Media Player has sent subtitles and captions to screen readers for some time now, by default, using aria-live="polite"
and role="region"
on the subtitle container div
in the HTML rendering.
Of course another reasonable option is to be explicit about what player behaviour
@nigelmegitt I do not think it is necessary to be explicit about player behavior. It is however necessary to be explicit about the semantics of elements and attributes. I fairly certain that tts:visibility="hidden"
Indicates that the element is not visible, perceivable, or interactive to any user -- to use the HTML definition (https://www.w3.org/TR/wai-aria/ and https://html.spec.whatwg.org/multipage/interaction.html#the-hidden-attribute). If the element is intended to be provided to a screen reader even though it is not rendered, then another attribute/element/track would be necessary.
[ed.: added reference]
Ah, I had assumed that complete removal from the tree would be done by setting display: none;
or tts:display="none"
. MDN suggests that a combination of properties can be used to make content visually invisible but available to screen readers, however in the linked page none of them includes setting visibility
.
It's unfortunate that the HTML spec doesn't specify which CSS property is equivalent to making an element hidden in HTML. The fact that the note talks about setting the display
property to override the hidden
HTML attribute makes me think that the opposite is true too, that setting display: none;
is equivalent to setting the hidden attribute, but I don't think this is clear from that part of the specification anyway.
In the ARIA documentation I see that in all the examples they match the value of the ARIA attribute to an equivalent value of the visibility
property, for example in aria-hidden
- this makes me think they are not intrinsically linked and that maybe it is possible to vary them independently. There's also an explicit mention of display: none;
content never being rendered regardless of anything else, which is what I would expect.
If it is legitimate to use visibility
in the way I proposed, then we should not add anything else; however if it is true that setting visibility: hidden
forces the content to be hidden from the screen reader too, then I agree we may need to specify something special.
however if it is true that setting visibility: hidden forces the content to be hidden from the screen reader too, then I agree we may need to specify something special.
I suggest exploring approaches in that direction, e.g. a dedicated attribute.
Note that, in the case of forced text, it turns out that, in many scenarios, a dedicated track is created -- instead of using itts:forcedDisplay
. This is necessary because the forced text shown on the screen changes when the non-forced text is displayed, e.g. there is less space for the forced text. So it might be the same here: a dedicated track might be needed for the "text-for-the-visually-impaired" use case.
@nigelmegitt you probably know this, but display
is very distinct from visibility
, in both CSS and TTML: display
controls whether (and how) content layout occurs, such that if it does occur, then it (generally) consumes layout space (in visual media), while visibility
controls whether marks generated for that space are rendered (presented) or not; e.g.,
<span>Foo</span><span tts:display="none">Bar</span><span>Baz</span>
has no space between "Foo" and "Baz", while
<span>Foo</span><span tts:visibility="hidden">Bar</span><span>Baz</span>
has space (the width of "Bar") between "Foo" and "Baz";
the reason I'm making this comment is because I was not sure you made this distinction in your comment above;
Yes @skynavga I was aware of that; I did not make the distinction because I was only concerned with which property matches the HTML @hidden
attribute, and because in the use case I have described, it isn't likely that there would be some inline hidden text in amongst non-hidden text. However, taking that semantic into account, the WHATWG specification of the @hidden
attribute appears to fit more closely with display: none;
than visibility: hidden;
.
@palemieux I understand some content providers have made that choice; in this use case the forced text does not affect the non-forced text, so it is likely to be significantly easier to distribute a single TTML file and have the player switch presentation of the non-forced parts. If we can make it work, forced seems like a good fit.
If we can make it work, forced seems like a good fit.
@nigelmegitt Sounds good. Can you propose an approach that is consistent with TTML, IMSC, ARAI, HTML, WCAG and MAUR?
Can you propose an approach that is consistent with TTML, IMSC, ARIA, HTML, WCAG and MAUR?
@palemieux I had thought that proposing tts:visibility="hidden"
and having the player put the content into an ARIA live region would achieve that, so that's my baseline proposal until anyone tells me it doesn't work.
had thought that proposing tts:visibility="hidden" and having the player put the content into an ARIA live region would achieve that, so that's my baseline proposal until anyone tells me it doesn't work.
The proposal as it stands does not work IMHO since it changes the semantics of tts:visibility="hidden"
, which today means not visible, perceivable, or interactive to any user.
Can you propose an alternative/tweak?
tts:visibility="hidden"
, which today means not visible, perceivable, or interactive to any user.
@palemieux I haven't found any specification text to support this, looking at TTML2, and the derivations at XSL-FO and CSS - at the moment my understanding is that setting visibility to hidden is not the same as setting the hidden attribute in HTML, and only affects visual presentation.
I've been experimenting with this in HTML and CSS and JS on Firefox and so far my experiments seem to bear this out(apologies I have to stop this soon and haven't got a clear shareable example yet):
span
where @hidden=true
has been set becomes visible when setting display: inline;
span
where @hidden=true
has been set does not become visible when setting visibility: visible;
span
with visibility: hidden
reports @hidden = false
.span
with display: none
reports @hidden = false
.In the first two cases, querying@hidden
after changing the CSS property results in true
. So a hidden
thing that is visible
and has display: inline
is still rendered.
The only consistent thing I've found is that setting @hidden = false
on an element makes it disappear.
Right now it is not clear to me how this is supposed to work, but I haven't managed to work my way around to understanding how the @hidden
attribute's description relates directly to anything in CSS. One thing I notice is that it includes the text "User agents should not render elements that have the hidden attribute specified." - interesting "should" there!
@nigelmegitt Have you considered defining an explicit attribute, akin to forcedDisplay
, but for screen readers? Any downside? Would a potential next step be to seek feedback from CSS and the accessibility WG?
Have you considered defining an explicit attribute
@palemieux I'd consider a new attribute if I felt certain that there is no existing way to get the same effect; I'm not really convinced of that yet, but it certainly wouldn't harm to get feedback from those groups. I'll ask them.
Further evidence: https://github.com/w3c/csswg-drafts/issues/560 and https://developer.mozilla.org/en-US/docs/Web/CSS/visibility#Accessibility_concerns suggest that as you stated @palemieux setting visibility: hidden;
also should hide the content from the screen reader, and that other people have asked for this too.
The Timed Text Working Group just discussed forcedDisplay and visibility="hidden" imsc#484
.
Currently the specification for
itts:forcedDisplay
in both IMSC 1.0.1 and IMSC 1.1 suggests in the introduction that it only applies to content for which the value oftts:visibility="visible"
but the normative text does not actually make that distinction.We have a use case for using
itts:forcedDisplay="true"
andtts:visibility="hidden"
for the same content: the idea is that when text is burned into video and has no equivalent sound an "invisible" caption is forced on to trigger reading by a screen reader, i.e. producing an audible presentation without producing "any visible rendering".We want to do this in the short to medium term without having to advance to full adoption of
condition
, and this (direction of text to a screen reader) is not a candidate for the use oftta:speak
which is itself not conditional on there being an active screen reader.I don't think this alone is adequate to trigger the release of a new version of IMSC, however if one is being prepared for any reason, I would propose changing the opening sentence from:
to
and add a note: