This week we’re still talking about video. They say a picture can say one thousand words. Video is thousands of images that tells us more than what the audio alone says. Most video on the web these days is between 24 and 30 frames per second. That potentially would put a one minute video at roughly 1.8 million words. Even if 30 frames equal one picture, you are still responsible for up to 60,000 words. How do we do this?
Comments closedNothing super high level this wee. Two weeks ago I mentioned how you need to have captions on your site. If you haven’t read that article yet, take a few minutes and do so.
This week we’re talking about captions in a live scenario. When we consider closed captions on a prerecorded video, we could send the video to a transcriptionist. The transcriptionist would then build our caption file. But what if you are doing a webinar or streaming?
Comments closedWhat is an Audio Description? Video has two main elements to it, what you see and what you hear. Imagine you go to watch Back to the Future. However, your vision has failed to the point where you can’t see the image. Audio description comes in to make it possible to get the visual cues needed to follow the plot. Let’s take a look at what they do.
Comments closedWe’re still working with video and audio in 1.2.2. I’ve mentioned captions in the previous A11y 101 posts. Success Criterion 1.2.2 lays out the specifics for captions.
Simply put, if there is video with speaking you need captions. Did you provide an audio description? Those get added to the captions.
There are two basic ways to provide captions, open and closed. In either case, you need to have someone transcribe the audio. They need to include the time when the display of the text starts.
Open captions are the minimum support you should provide. Open captions are “printed” into the video. They are baked in and designed to fit the design aesthetic of the video.
Why do I call this minimal? Well the user lacks control to customize it. Additionally, this only supports deaf and hard-of-hearing folks. Our next version offers more features.
Since open captions are part of the video, they can actually create problems. The most problematic is that they may move around the screen depending on what the video needs. This makes it hard for users, especially low-vision users, to keep track and find them.
Closed captions provide and answer to this. Closed captions are a separate file called in the <video> element. Usually it is a .VTT file. It’s pretty simple to build. I have an article on a11yproject.com that I published in 2013 that explains how to do it.
The next thing that closed captions bring – screen reader and Braille display support. Closed captions are considered real text on the page for screen readers. Now the Blind-Deaf can get the story too. The low-vision user can lean back on the screen reader to help. It also helps with SEO.
Comments closedI discussed non-text content last week and mentioned video. WCAG decided to be specific when addressing items that fall under the bigger 1.1.1 criteria.
In success criteria 1.2.1, we’re informed we need to provide one of two options, unless the audio or video IS the alternative. Let’s look at our options:
https://www.w3.org/WAI/WCAG22/quickref/#audio-only-and-video-only-prerecorded
- Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.
- Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.
OK, what are our key words? “Time-based media” is mentioned in both. We see in three places, this is about pre-recorded media and not live. This means we can use the edited audio or video. We can then give it to someone to create a transcript. They can also make closed captions for videos.
Once returned, we offer a link to the transcript. This can be an accessible PDF, but it is often easier to to make it HTML. The transcript doesn’t need to live on another page. The preferred method is to use a disclosure next to or below the media. When closed the content is hidden. The user who needs it, can expand the transcript to read.
If we are working with video, does it have an audio track that describes everything in the video? This is usually an audio description track. It’s provided in addition to the regular audio track. It will describe what is happening without needing to see. One of my favorite examples is a Frozen trailer:
Transcripts are easy. There are many ways to get them done, and some are super cheap. But before you ever put the transcripts on your site, have someone, better yet several, proof them.
Comments closedOne of my roles as a consultant is to coach others. Clients & colleagues, from junior testers to CEOs. Each of them learns in a different style. That is why I’m starting this A11y 101 (short for accessibility – pronounced “ally” or “a-eleven-y”) series. It will break down some of the major topics in different ways. This approach hopefully connects easier than technical specification documents.
What is “non-text content”? The Web Accessibility Content Guidelines (WCAG) makes it pretty simple, if it isn’t text, it falls under here. As a developer, you are promising that there is a text fallback for the non-text content.
Videos, images, charts, animations are all examples of non-text content. Some times these are decorative. Sometimes they add meaning. When we are talking about non-text content, we really only mean meaningful non-text content.
For video, we have two options for text alternatives, captions and transcript. Captions come in two types. While both cover the text alternative for video, one carries us beyond 1.1.1. Users can choose real-time captions. Alternatively, they can take their time to read the transcript.
Open Captions are captions that are embedded into the video. They can be positioned within the video to maximize the visual. Yet, this jumping around the view can be problematic for users. Additionally, this style of captions are not screen-reader accessible.
Closed Captions consist of a separate file the user can turn on and off. Each file will include a time-stamp followed by the words used on screen. Bonus feature is that closed captions can be read by screen-readers and Braille displays.
Not everyone reads at the same speed. Many factors affect reading speed. People with issues like TBI, ADHD, Dyslexia, or low literacy may need to slow down the tools. This allows them to read at their own pace. Transcripts allow this as well as supporting screen-readers and other assistive technology.
When deploying a video to your site, the best practice is to provide both the transcript and closed captions. You can save yourself time by creating the closed caption file, then using that to create the transcript. It works the best when the transcript is HTML loaded directly next to or under the video. This can be behind a disclosure or a link to another page. You can provide an accessible PDF as a transcript. Still, these are rarely easier to create than HTML.
Images are the first thing we think of when we think non-text content. There are many image types available. We need to consider just a few methods to provide a text equivalent. This is highly dependent on how you call your images.
<IMG>
When using the <img> element, it MUST have the “alt” attribute in the tag. Here we provide a value that doesn’t describe the image, but rather the meaning of the image. Keep this in mind, we’ll talk more about it later.
<SVG>
There are several ways to place an SVG into a page. This technique addresses when the <svg> is placed into the HTML. First, we need to understand the SVG and how it is to be used.
Static image placed on the page? Then we can provide aria-label and put the meaning there. We could also provide the meaning in the SVG <title> element. Provide an ID and use aria-labelledby. This is super handy if your design teams are building SVGs this way.
Referenced by the <img> element as the source, use the rules for <img>.
Inside the <picture> element? The picture element requires several source files, but also includes a fallback to the <img> element. In the picture element, the alt text of the fallback image serves as the text alternative. So, don’t leave it out!
Using the <figure> element? This is a fun one because it combines all the techniques into one. A figure can have anything in that creates some sort of drawing. Whatever you put inside will dictate how to create the text alternative. For example, you can use an <img> inside. Or <svg>. In either case, we’d use the same rules as above.
Of course you could also draw something with HTML & CSS. In this case we provide an aria-label on the wrapping element of the drawing and also provide a role="img".
Figures also allow us to provide a caption using <figure>. While it is not required, if there is a complex message this is where we put it. We still need alternative text for the image, but we can go into more detail here.
Canvas is a really cool set of tech we can use on the web. Yet, due to it’s nature, it isn’t really accessible. You can put HTML between the canvas tags. You can map the bitmap images to HTML elements. There are easier ways to do this too.
Always provide an aria-label; or aria-labelledby on the canvas element. Your descriptive content can live inside the canvas element and still be referenced.
Charts and animations are a combination of the above. Usually charts are crafted using SVGs on the client side or static images on the server side. Animations are usually made in JavaScript with SVGs or Canvas.
Keep in mind, that charts get complex really quickly. You should strive to provide two types of interaction:
Lastly, if you can, provide a summary for the chart. These usually either lead or follow the table in the HTML.
Comments closedI love concerts. People performing live music is one of my greatest pleasures. Music is critical to my soul and is beyond crucial for keeping up my mental health.
My wife is less thrilled with concerts, but is always up for a fun time with the right people. Weird Al announced a tour with Puddles Pity Party. Two of our favorite artists. One of the stops is our home town just after our anniversary. One of our closest friends is also a fan and knows Puddles. Off I went looking for tickets!
Checking out the tickets I saw that Ticketmaster and StubHub were selling them. I know that resellers like StubHub tack on additional costs and fees. I do my normal thing and head directly to Ticketmaster instead.
My wife has POTS, so when we go out she is in a wheelchair. I have a vestibular disorder that makes standing for long periods impossible. It is made worse with loud environments and big crowds (Sounds like I shouldn’t go to concerts, huh?). So we can only go to shows that have seating & wheelchair accommodations.
The location they are playing at is mostly general admission to stand on the field. It’s a stadium, so there is some seating. Ticketmaster showed only 1 wheelchair accessible ticket. Most of the seated areas were marked “sold out” a day after release. I decided to check StubHub for those “sold out” areas.
StubHub showed there are tickets in areas where Ticketmaster said tickets were sold out and I’m thinking, “Options!” StubHub does not provide a way to filter for disabled seating!
We went to see Marc Maron last year. I opted to buy, from TicketMaster, an “Accessible seat” on an aisle. Upon arriving to the facility, the accessible seat was a regular seat. No where in the purchase process did it say it wasn’t wheelchair compatible.
The onsite TicketMaster people helped move us to the ONE wheelchair seat as it wasn’t sold. There was only space for one chair and one companion. And of course another wheelchair user showed up and they stuffed them in with us.
I learned from this that even if TicketMaster says there is accessible seating, it may not be wheelchair friendly. And the only way to actually buy accessible tickets is to call the venue.
We aren’t going to see Weird Al or Puddles. The one “accessible” seat won’t work for a wheelchair user.
Comments closedThis week I had a bunch of requests from clients surrounding VPATs and ACRs. This article will be a living article where I’ll post extra questions I receive as they come in.
Comments closedWhen it comes to writing code that supports accessibility, there can be multiple ways to solve a problem. The industry has worked hard to standardize interactions so that component types function the same across environments. But, it avoids being dictatorial in how to remediate a given problem by only providing generic code samples.
Likewise, when we conduct accessibility audits, we will face user experiences that do not make sense to us. Nevertheless, the client is invested in these experiences. Perhaps the client has limited bandwidth to do remediation. The complete and proper resolution can be more than the client can get done in a reasonable amount of time. Yet, we want to help them achieve an accessible solution sooner.
In these cases it isn’t always appropriate to tell a client they need to completely change their code. Sometimes the solution is a small modification. Let’s examine a recent situation I encountered. A modification can fix the problem, even if the ideal remediation is a code change.
My client presented a website with some filters at the top of a table. The client initially coded the filters as multiple buttons per the design team’s layouts. Each button filtered the table in a different way, and only one filter can be used at a time. You can also have no filter applied. Upon examination, these buttons were properly constructed, but missed a state attribute and aren’t grouped.
I can justifiably tell the client to remove the buttons. They should replace them with radio button elements instead. Then, restyle them to look like a button grouping with one pressed. For no filters, we’d offer up a “Unfiltered” choice. And this will certainly fix things. In the long run, I want the client to follow this plan. It’s the most complete solution.
This change means the client needs to dig into their JavaScript. They must find the code related to the filters. Then, update it to respond to radio buttons instead of button elements. The client’s front end team will need to write new CSS and HTML. But remember they have limited resources, and we need them to fix things as soon as possible.
There is another perfectly valid way to fix the problem. I can coach the client to add the aria role of “group” to the wrapping container. They should also add aria-pressed to the active filter button. This informs assistive technology that these items are related. It also fixes the state issue where we don’t know which filter is active. This solution takes roughly 10 minutes to fix, where the full remediation to proper radio buttons will take significantly longer.
The simpler recommendation may allow the client to fix more issues with the resources they have. Every step is a move towards better accessibility. Take the time needed with your clients to understand their current situation and needs before writing your recommendations. Don’t be afraid of offering up a “quick fix” for a client, as long as it actually fixes things.
Comments closedWhen it comes to accessibility for digital products, we look to the W3C’s Web Content Accessibility Guidelines (WCAG) to point us in the right direction. WCAG carries with interaction guides to how users can expect a digital product to respond regardless of their method of interaction. This common language we use to make sure that a website, application, kiosk, mobile app won’t be confusing to new users. However, WCAG isn’t prescriptive in demanding things be done a specific way. And more importantly, just like accessibility isn’t a destination, neither is WCAG conformance. Its just the baseline we start from, we can go beyond it.
Keeping things generic for a moment, what does it really mean to go beyond a standard? This may not be clear of possible in all situations, but to go beyond a standard, we need to first achieve that standard, then add features that enhance the usability and user experience.
We’ll establish that this is an ecommerce site. During development, we add a link to the end of each product description. To meet the guidelines we’re working with we need to make sure it stands out from surrounding text. To make it standout, we underline it and use a different color. For this imaginary link, the color we choose has a 3:1 contrast with the surrounding text and 4.5:1 with our background. This meets the barest of guidelines laid out in WCAG. But we can do more than this.
We’ve already cleared WCAG 1.4.1 Use of Color as we have our link underlined. Next, let’s look at the text. Our link is in the middle of a paragraph describing a product by Acme MFG, inc. The link reads, “More information” immediately following the product description.
The Acme MFG Ultra Juicer 3000 is a state-of-the-art kitchen appliance designed for health enthusiasts and busy families alike. With its powerful 1000-watt motor and innovative cold-press technology, this juicer efficiently extracts maximum nutrients from fruits and vegetables. The Ultra Juicer 3000 features a wide chute that accommodates whole fruits, reducing prep time significantly. Its quiet operation and easy-clean components make it a convenient addition to any kitchen. The juicer comes with multiple speed settings, allowing users to customize their juicing experience . Acme MFG’s commitment to quality is evident in the juicer’s durable stainless steel construction and 5-year warranty. More Information.
Some of you are probably getting wound up by the name of the link, be patient, because the above link passes WCAG 2.4.4 as it has context before it. It is reasonable to assume the user knows this link will take them to more information on the juicer. However, if that link were brought up in a link list as most screen readers provide, it loses the context and reads, “More information” in a list of links that may or may not be unrelated. Most of would go back and revise the link to read, “More information on ACME Ultra Juicer 3000.” And this is great! It takes this particular issue and meets WCAG 2.4.9 AAA. But have we gone beyond WCAG?
A lot of times we provide controls to do something on the page. Most accessibility specialists will recommend that the control tells you what it does. Our link above will take you to the ACME website for details and service manuals.
WCAG doesn’t directly apply to this.
The industry as a whole agrees that if a link or button opens a new tab, window, or dialog that the user should be alerted that control will do just that. But WCAG doesn’t address this. We add icons (with alt text) or text saying “opens in new window”, “opens dialog”, or similar to inform the user what is going to happen. We do this to prevent surprises, confusion, and disorientation of the user.
Going Beyond WCAG means that you recognize that accessibility is the first step in a good user experience, but a good experience isn’t enough. Great products have great experiences, so combine your accessibility knowledge with usability and user experience. And if you are a designer, great accessibility is great user experience, don’t discount either.
Comments closed
