Feat/access-video: adding video to accessibility page #2477
Conversation
| At HPE, we believe in being a force for good. We solve for humanity with humanity. We use technology to make the world better. We are unconditionally inclusive. **We believe that being accessible is a requirement, not an option**. | ||
|
|
||
| In the video below, Bill Tipton, an HPE Product Accessibility Champion, discusses his role and the importance of inclusive design and development. The video shows Bill, a white man with blondish brown hair and a mustache, in his office wearing a long-sleeved lavender-blue dress shirt with the HPE rectangular-shaped, multi-color logo against a black background as the background. |
There was a problem hiding this comment.
The second sentence seems like it belongs in an aria-describedby and <div /> added as a child of <video />. Is there a reason it should be in the main content flow?
There was a problem hiding this comment.
bill and i had discussed this a way to provide an audio description for users but i think i could incorporate it with the aria-describedby as you mentioned and see what bill's experience is with that! that way it isn't unnecessary content on the page
|
|
||
| return ( | ||
| <Box width="large" pad={{ bottom: 'large' }}> | ||
| <video controls> |
There was a problem hiding this comment.
Should we be using the transcript attribute and providing a transcription html file?
There was a problem hiding this comment.
yes! will be adding this today
There was a problem hiding this comment.
just a heads up, i added the transcript file via a clickable link after the video that will open the html page. bill says this aligns with current best practice as a user will could save this page as a pdf if they wanted to digest the transcript offline.
i don't think the transcript attribute is implemented in HTML5 but is just an idea at the moment for future improvements to the <video />
| width="large" | ||
| pad={{ bottom: 'large' }} | ||
| > | ||
| <div id="video-alt" style={{ display: 'none' }}> |
There was a problem hiding this comment.
I would have expected this div to be nested in the <video> tag after the <track>. Is there a reason for having it outside?
There was a problem hiding this comment.
When testing this myself and Bill with the div inside the <video />, the information wasn't being read aloud by the screen reader. It was only relayed with this div being outside of the <video />.
For my most recent changes, you will see that I am using aria-description instead of aria-describedby, as Bill was still having some issues with getting the description read aloud using JAWS. They serve the same purpose, but have different levels of support/implementation. Using aria-description works for me on VO and I am hoping Bill has a better experience with JAWS.
There was a problem hiding this comment.
For my education, can you share any resources speaking to aria-description vs aria-describedby? I'd like to better understand why aria-describedby wasn't working. Is is fundamentally flawed? Was it a flaw in our implementation? It is so widely referenced and documented, that it seems like we should deeply understand this so that we are aware of pitfalls and can recognize and abate them.
| width="large" | ||
| pad={{ bottom: 'large' }} | ||
| > | ||
| <Box |
There was a problem hiding this comment.
Why are we using a Box here? This seems to be acting a button.
| pad={{ bottom: 'large' }} | ||
| > | ||
| <Box | ||
| a11yTitle="Audio Desciption" |
There was a problem hiding this comment.
| a11yTitle="Audio Desciption" | |
| a11yTitle="Audio Description" |
| <FormDown a11yTitle="Down arrow" /> | ||
| } | ||
| </Box> | ||
| {expanded && desc} |
There was a problem hiding this comment.
This pattern of having the audio description visibly ahead of the video is new to me. Can you share any resources, examples, etc. which are inspiring this direction?
As we implement this experience, we should be thinking of it as it is setting a foundational pattern for how rich content is presented, so having notes, references, etc. to document our thinking and approach would be valuable.
There was a problem hiding this comment.
sure! after working with bill with numerous testing rounds, he had shared that the audio description through aria-description and aria-describedby was not consistent in the reading of the description. while when testing with VO i was able to hear the description at the video start and end, he was not able to get it read consistently with JAWS or NVDA.
to ensure that the description would be read aloud at some point, bill mentioned that another pattern he has seen before is to provide a way on the same page as the video for screen readers to get the description, either as hidden text on the page or a button that triggered the description to be shown.
in response to why aria-description and aria-describedby were flawed, it seems that the <video /> doesn't have great screen reader support with related props as shown here and here. aria-describedby also seems to be mostly used with form elements, but when used with other elements like <img />, the support changes drastically as shown here. the same could be said for aria-decription since it functions the same way.
based on my testing with VO and with bill with JAWS and NVDA, it seems there is varied support around both of these aria attributes and so we took the approach of displaying the audio description in some way on the screen so users with screen readers can find it. we also included the a11yTitle for the audio transcript file to relay that an audio description could also be found there, which is common practice.
There was a problem hiding this comment.
Feels like we should have guidance on DS site of how to implement this. I don't know if we have a "Video" component page, but this kind of information would be helpful and important to share there -- even if videos are less common UI elements for our apps. Maybe a ticket should be filed for this?
There was a problem hiding this comment.
Couple of questions on the approach though:
- I'm wondering if the audio description should go beneath the video instead? It feels a bit too prominent. Also it feels more like a "Video Description" to me than an audio description, because we are describing the visuals.
- Could we potentially mirror the design approach that Ted Talks takes (showing the transcript inline on the page) -- maybe for our use we can mirror the "Show Code" approach but instead have "Read Transcript" as the collapsible label: Example on TedX approach when you click "Read Transcript" https://www.ted.com/talks/jill_bolte_taylor_my_stroke_of_insight
- The "Audio Description" is already repeated at the start of the transcript. Is there any reason we need to have both?
There was a problem hiding this comment.
Agreed with having guidance reflecting these Video considerations on the DS. To your other points:
- the terms "audio description" and "video description" are used interchangeably in the a11y community and usually come before the video to properly set up the context of the video. i had it as "audio description" because we are describing the video through audio for screen reader use and bill had mentioned that was the terminology he was used to. i can change to "video description" if you feel that's more appropriate!
- i had originally thought about the "show code" approach and making use of that component/pattern as it exists in the DS, but my big thing there was the accessibility of the code snippet piece as logged in this issue. the other piece to this was the fact that transcripts should allow for a user to download the file, as pointed out by bill. i think it could be worth it to explore how we could add the inline transcript and allow for downloading the file in our Video component. i could approach this in the same way that i'm handling the expandable description if that would be better but bill noted his experience currently is accessible and up-to-standard.
- the "audio description" is included in the transcript file as it should be accessible at the page level that the video is on and included in the file itself.
let me know your thoughts!
There was a problem hiding this comment.
I am very much in support of ensuring all the necessary accessibility requirements are met so those using assistive technologies can have an equal experience to those not. That being said, I want to be mindful that the assistive technology support doesn't clutter the UI or disrupt the usability of a page for users not relying on the assistive technologies, as this could create a poor experience in the opposite direction. That's where some of my design comments are coming from.
Personally, I found the "Audio Description" button to be a bit disruptive to the page flow because it comes first and draws a lot of attention to itself, which is why I'd be more in favor of it coming below the video. Good note about code snippet issue, I'm fine with exploring it implemented how you handled it as opposed to the show code approach but maybe placing underneath the video?
For the case of needing to be able to download the transcript, maybe we can have the transcript appear inline but also provide a download button for those who would want to download it? I think an icon-only button would be sufficient with an a11yTitle="Download transcript" ?
| width="large" | ||
| pad={{ bottom: 'large' }} | ||
| > | ||
| <div id="video-alt" style={{ display: 'none' }}> |
There was a problem hiding this comment.
For my education, can you share any resources speaking to aria-description vs aria-describedby? I'd like to better understand why aria-describedby wasn't working. Is is fundamentally flawed? Was it a flaw in our implementation? It is so widely referenced and documented, that it seems like we should deeply understand this so that we are aware of pitfalls and can recognize and abate them.
|
@taysea @halocline for the latest changes, i've moved and renamed the audio description button to be below the video and now read as "video audio description". i've also changed the transcript file to be a button as well to align the UI and also help screen readers identify that an action will be triggered. as far as the expandable transcript, i think it would be worth it to explore the inline implementation. for the sake of getting this published, i wanted to propose opening a ticket adding this functionality, as it would require another round of user testing with Bill to ensure it's an accessible experience. this is something i can pick up as a "version 2", but i didn't want that to get in the way of publishing this "version 1" since the accessibility of this UI has full coverage and more testing may postpone the release. does this sound reasonable? also added this ticket |
After your share-out last week and subsequent discussions, I propose the following:
Proposed adjustments:
@taysea , @amandadupell do these proposals and direction resonate? Thoughts? Adjustments? |
|
Agree with your recommendations @halocline. And nice work on some of these adjustments @amandadupell. Two things I'm noticing which I think would be nice to resolve before merging (but I think we're very close):
|
We can remove. I suggest we add
I would expect the "Transcript File" to maintain its position in the row. |
What does this PR do?
Adds Bill's video to Accessibility page
Where should the reviewer start?
Accessibility.mdx
What testing has been done on this PR?
Manual local testing
In addition to the feature you are implementing, have you checked the following:
General UX Checks
Accessibility Checks
Code Quality Checks
How should this be manually tested?
Deployment
Any background context you want to provide?
The paragraph before the video serves as an audio description for blind or visually impaired users. It also provides context for what the video's purpose is and who Bill is.
What are the relevant issues?
#1816 #2453
Screenshots (if appropriate)
Should this PR be mentioned in Design System updates?
Yes!
Is this change backwards compatible or is it a breaking change?
Compatible