Hi all, I'm currently working on a project for an Australian based non-profit. We will need to ensure that we meet accessibility requirements, in particular video. I'm curious to know what the best practice approach is for the Adapt settings available to ensure transcripts/closed captions are easily visible. I'm looking for a consistent approach, would anyone be willing to share screenshots of how they are configuring?
Best practice YouTube embed - meeting accessibility
Re: Best practice YouTube embed - meeting accessibility
Hi Tyson
You say 'YouTube embed' in the subject line - could you be clear about what you mean about that? Do you mean using the standard contrib-media video component with YouTube as the source? Or using a 3rd party component like adapt-youtube?
We would generally stay clear of embedding YouTube video when accessibility is a requirement and would instead using MP4 video inside the course.
As for accessibility settings, that frequently depends on the client's requirements. Some require an inline transcript, some require an external transcript. Some require closed-captions, some don't. Some prefer subtitles to be 'burnt in'. Some require a combination of these. At the very least, you should pick one. I would also say that if you are using a transcript you should apply the _setCompletionOnView setting otherwise a user viewing only the transcript will not be able to complete the video component.
Re: Best practice YouTube embed - meeting accessibility
Hi Matt, thanks for responding so quickly. Apologies I should have been clearer!
We are using the standard contrib-media video component with YouTube as the source via the authoring tool. We are hesitant to use .mp4 video due to the need for some of the users to access the content in regional areas of Australia where they are not blessed with fantastic internet speeds, thus we are keen to take advantage of YouTube bandwidth detection, etc.
Understand that client's will have different requirements, however I'm trying to get an idea of what works best for the majority. We are dealing with an audience of predominately older users in the 40+ aged bracket , often accessing via 2nd hand phones . My feeling is that forcing CC on via YouTube somehow may be the best option in combination with Inline transcript (trying to avoid having users link out), however unsure if this is possible via the media component? Has anyone had success with this?
The content we are creating we are describing as optional (happy to give some more context around the content via PM) "snapshot" series, there is no formal completion tracking/bookmarking required.
Re: Best practice YouTube embed - meeting accessibility
Another big issue with video and accessibility is handling Audio Descriptive tracks (an optional audio track that describes the video images for people with poor vision).
WCAG AA 2.0 requires it, which means that all video on Australian Government websites require it.
Youtube won't do it, Vimeo won't do it and I'm pretty sure that Mediaelement.js that Adapt uses doesn't do it either.
I'd be interested to hear how others are working around this requirement. Either by putting audio descriptions in the main audio track, or by making video so dull (presenter to camera only) that nothing needs describing.
Ideally, we could create an alternate audio track that could be enabled like a subtitle is. With a button that a screenreader user could enable easily via keyboard.
Any plans to make something like this work?
Re: Best practice YouTube embed - meeting accessibility
Hi Joe
If you read into the detailed descriptions on this over at the WCAG is seems that it's only proprietary plugins/players (such as RealPlayer, Flash and QuickTime) that support audio description tracks - the HTML5 player within browsers themselves don't support it ("most user agents today cannot merge multiple sound tracks" source: G173: Providing a version of a movie with audio descriptions).
G173 suggests that the best way to meet this is therefore to provide two versions of the video, one with the audio description and one without.
Alternatively H96 suggests simply using the <track> element to include audio descriptive subtitles, this should be possible with adapt-contrib-media. H96 does show the addition of a kind attribute set to "descriptions" which isn't currently supported - but you may find that added this has very little impact anyway. It would be easy enough to test to see if it is really a requirement or not.
It's important to remember that the functionality of HTML5 video is specced out by w3.org but then has to be implemented by the different browser manufacturers. If they don't implement something there's often not much can be done about this by content developers...
Re: Best practice YouTube embed - meeting accessibility
Hi Matt,
This is really useful info.
So what would the best solution within Adapt be to provide two versions of a media element? Have two components in a block with instructions to users and screen readers?
It would make it a little tricky if watching the media was a requirement to completion I guess, as users would only watch one of the two provided. And kind of annoying to sighted users to scroll through duplicate videos all the time.
Providing a <track> element would require the screenreader to read out the descriptions alongside the audio track. Do you know if any screenreaders support it? I'll do some tests and report back.
Joe
(sorry if I took this topic "offtopic")
Re: Best practice YouTube embed - meeting accessibility
Depends how much you do/don't want to customise Adapt. If you need to be using Adapt out-of-the-box then using two media components side-by-side is probably the best option and yes, making them mandatory for completion wouldn't really work.
If customising Adapt is an option then I'd look to add some kind of accessibility settings feature that the user could be presented with at the start of the course that would allow them to select things like audio description and you could customise the component to switch out video files depending on what setting had been chosen.
Do you know if any screenreaders support it?
No I don't, sorry
I think in the case of most elearning content, screenreader users are generally very well served by a transcript of the video as this can be parsed and read back by screenreader software at high speed rather than being constrained by the speed of the video. It really depends on the video content; i.e. 'talking head video'. But I appreciate that if you have a client who insists on sticking absolutely to the line of the WCAG then any attempt to take a pragmatic line is doomed to failure - particularly as they are guidelines and not rules and so (deliberately) open to interpretation...