To AG Reviewers

[shawna-slh]

Draft for Review

Status:

• complete draft of all content ready for review
• images are drafty and in-progress (images status)
• there are a few open issues -- e.g., for EOWG comment <-- and we welcome your input on those, too
• this draft is fairly stable, yet we might have some edits based on review from others

We would especially like AG to review the following information directly related to WCAG requirements:

• WCAG Standard
• Checklists for Audio and Video
• in description page
• in captions page
• in transcripts page
• in media player page
• some small sections of Accessible Audio Content and Video Content

If you have any significant comments, especially that need EOWG discussion, it would be very helpful to get those by Tuesday 13 August.

Your comments:

• Please indicate each comment as high, medium, or low (e.g., nitedog comments)
• If you have several wording changes, editor(Shawn) prefers GitHub Pull Requests for each, or the page with tracked changes in a document (contact Shawn for more info)
• Especially if there are points that we want to get more input on from EOWG, feel free to open new GitHub issues. Please open a new GitHub issue for each point. Thanks!
• If not using GitHub and sending comments via e-mail, please CC the publicly-archived list wai-eo-editors@w3.org as appropriate

Use cases and tasks are in Requirements Analysis for media resource.

Feel free to contact editor/Shawn if you want background on the decisions EOWG made, for example, on the title.

[shawna-slh]

For changes since call for AG review on 24 July and telecon agenda on 6 August, see History

[lauracarlson]

Hi Shawn,

Many thanks to you and EOWG! This will be a great and sorely needed resource. I have no substantial comments but noticed one minor typo on Making Audio and Video Media Accessible:

"an described version" should be: "a described version"

Thanks again, Laura

[shawna-slh]

Thanks very much for your review, Laura! Fixed typo/wordo. :-)

[jasonjgw]

This is a very good draft. On the "transcripts" page, "A live steam" should be "stream".

There have also been issues raised recently in W3C contexts regarding the proper placement and treatment of captions in 360-degree video. It may be useful at least to note the problem, even if we don't have solid guidance to offer at this stage. (There is relevant research by the BBC that resulted in a published paper, but, so far as I am aware, no broad consensus on appropriate practices.)

[shawna-slh]

@jasonjgw said:

This is a very good draft. On the "transcripts" page, "A live steam" should be "stream".

Fixed, thanks. (although "a live steam" might be great for those who like saunas ;-)

There have also been issues raised recently in W3C contexts regarding the proper placement and treatment of captions in 360-degree video. It may be useful at least to note the problem, even if we don't have solid guidance to offer at this stage. (There is relevant research by the BBC that resulted in a published paper, but, so far as I am aware, no broad consensus on appropriate practices.)

Right. Maybe the best option is to allow users to set preferences. For example, with one player, users can position captions below the video. Anyway, this resource isn't providing such specific guidance on captions position and format. It's also not covering newer issues that don't have established solutions.

I did update Positioning and Styling Captions.

[jasonjgw]

I also noticed that the process of generating captions/descriptions/transcript from an already scripted video wasn't directly addressed. If this is common enough to mention, even a sentence or two would be valuable, as this mode of working should at least save some portion of the accessibility effort. Screenplays are the obvious example, but not the only kind of case.

[allanj-uaag]

Hi Shawn, in the media player section "Accessible media players provide a user interface that works without a mouse, through speech interface, when the page is zoomed larger, and by screen reader users." you call out screen reader users. perhaps say with screen readers in Player Functionality the controls need to have sufficient contrast. Many of the native browser players have poor contrast on controls. in other parts of the media guide you mention multiple caption tracks. It should be a function of the player to not only turn captions on and off, but also select from all caption tracks available. Same for description.

[jpascalides]

Hi Shawn, one minor suggestion regarding the section "Understand User Needs".

It would be helpful to include a statement to the effect of: "Some individuals might prefer to use one or more accessibility features simultaneously to access content." This will help to ensure that the audience of this document understands that an individual may use one or more methods of accessing information. For example, an individual who is deaf might prefer sign language as their primary method of accessing content supplemented by captions or transcripts.

[shawna-slh]

Thanks for the review and comments, @allanj-uaag !

I revised this section: https://wai-media-guide.netlify.com/design-develop/media/player/#player-accessibility-functionality

"Accessible media players provide a user interface that works without a mouse, through speech interface, when the page is zoomed larger, and by screen reader users." you call out screen reader users. perhaps say with screen readers

done.

in Player Functionality the controls need to have sufficient contrast. Many of the native browser players have poor contrast on controls.

done.

in other parts of the media guide you mention multiple caption tracks. It should be a function of the player to not only turn captions on and off, but also select from all caption tracks available. Same for description.

For now we're not listing every aspect of media player accessibility. We point to MAUR:

More details on player accessibility functionality are in a separate document: Media Accessibility User Requirements.

(In the future, perhaps WAI will be able to provide an updated listing of player functionality (e.g., http://kensgists.github.io/apt/ )

I'm inclined to not list this detail -- partly because I think most common players do let users select from multiple captions/subtitles and because the Description page of this resource addresses player functionality for description.

I'm open to being talked into it if you are so compelled. :-)

[shawna-slh]

@jasonjgw wrote:

I also noticed that the process of generating captions/descriptions/transcript from an already scripted video wasn't directly addressed. If this is common enough to mention, even a sentence or two would be valuable, as this mode of working should at least save some portion of the accessibility effort. Screenplays are the obvious example, but not the only kind of case.

Ah, right. I would think that would be obvious – yet, we wouldn’t want people to miss it. I added to the Introduction of Transcribing Audio to Text:

In some cases, there is already text available in a script. You'll probably need to make some minor edits so it's accurate with the final audio content.

[shawna-slh]

@jpascalides said:

Hi Shawn, one minor suggestion regarding the section "Understand User Needs ". It would be helpful to include a statement to the effect of: "Some individuals might prefer to use one or more accessibility features simultaneously to access content." This will help to ensure that the audience of this document understands that an individual may use one or more methods of accessing information. For example, an individual who is deaf might prefer sign language as their primary method of accessing content supplemented by captions or transcripts.

Right. We have that idea in some places. For example in the Sign Languages page:

Some people will want to have sign language and captions at the same time.

I kinda don't want to repeat that example in the "Understand User Needs" section. For now, I added to the "Understand User Needs" section:

Some people use multiple accessibility features simultaneously. For example, someone might want captions, description of visual information as text, and description in audio.

I mildly feel that this is too much… (that section is already very long)