Skip to content

Nat Tarnoff Posts

A11y 101: WCAG 1.2.1 Audio-only and Video-only (Prerecorded)

A11y 101: WCAG 1.2.1 Audio-only and Video-only (Prerecorded)

Published on November 11, 2024

I 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:

  • 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.
https://www.w3.org/WAI/WCAG22/quickref/#audio-only-and-video-only-prerecorded

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 closed
A11y 101: WCAG 1.1.1 Non-text Content

A11y 101: WCAG 1.1.1 Non-text Content

Published on November 5, 2024

One 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.

Success Criterion 1.1.1 Non-text Content

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.

Video

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

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

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 & Animations

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:

  • Tab stops on all data points that convey both x & y titles and values.
  • Data table backup

Lastly, if you can, provide a summary for the chart. These usually either lead or follow the table in the HTML.

Comments closed
Ticketing Challenges: Finding Wheelchair Accessible Concert Seats

Ticketing Challenges: Finding Wheelchair Accessible Concert Seats

Published on October 24, 2024

I 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!

Previous Outings

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 closed
Understanding VPATs and ACRs: Key Insights
Improving Web Accessibility: Quick Solutions

Improving Web Accessibility: Quick Solutions

Published on October 3, 2024

When 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.

How do we help the client meet their goals?

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 closed
Going Beyond WCAG

Going Beyond WCAG

Published on September 23, 2024

When 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.

What does it mean to go beyond?

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.

Let’s try an example

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
GAAD 2024

GAAD 2024

Published on May 16, 2024
Selfie of Nat with the VeDA website behind him.

I’m taking a break today from my normal work of auditing and coaching clients on how to make their digital properties more accessible to celebrate Global Accessibility Awareness Day. GAAD is a time when industry professionals, accessibility advocates, and disability defenders make a concerted effort to bring the conversation to the front.

Now this may sound like what I do every day, and it is. My company asks us to do volunteer work, giving back to the disabled communities around us. And you may say to yourself, “Doesn’t Nat already do that?” And yet again fine reader you would be correct. I spend a significant chunk of my free time serving on the board of directors for the Wisconsin Council of the Blind and Visually Impaired. I contribute to the W3C.

But I’m not walking away and making excuses. This year I reached out to VeDA and volunteered to help them with their accessibility. I’m currently working on the audit, but once that is done, I will also help them repair the code base.

Take some time today to do volunteer in making someone’s life better.

Comments closed
You Need Accessibility Testing

You Need Accessibility Testing

Published on January 5, 2016

This probably isn’t the first time you’ve heard it. Somewhere along the line somebody asked you how well your site or application works for people that are blind. You probably mumbled something along, “They don’t use our stuff,” or maybe, “I don’t know, does it matter?” The short answer is, yes it matters. And you want to pay attention to why.

Accessibility isn’t Just the Blind

Accessible products and websites are often built with the blind in mind, however what it means to be truly accessible runs much deeper than that. Accessible by it’s very nature means that anyone, anywhere, with any tool of their choosing can use it. This means the disabled, which is not just the blind, but those with hearing, neuro-diversity, mobility, physical, and learning disabilities; and it means the abled that are compromised by other means.

Economics plays a huge part in accessibility. AOL still has 2 million people using dialup internet. This is an economic issue. ISPs have decided it isn’t beneficial enough to run faster lines to these areas or they are on fixed incomes and can’t afford the rising cost of internet access. Developing nations don’t have access to the funds to buy the latest and greatest technology, so they use products released years ago to get online.

As developers we all cheer when we hear that Microsoft is dropping all support for browsers below Internet Explorer 11 next week, but how does someone in an African country who can’t afford to upgrade from XP going to feel when we don’t support IE9? And what if that great new mobile application you created only works on iOS 9+ and Android 4.4.4? Many lower income folks in the developed and developing worlds have phones that are 2, 3, 4, or 5 years old and don’t support the latest things we can do with the web or mobile.

Building accessible products and sites means taking all this into account. It is using responsive web design to make sure your content is readable on all devices regardless of size. It is using solid HTML to make sure the content is parseable by a variety of technologies on the client side from browser, to apps, to refrigerators and TVs. It is using progressive enhancement to make certain that the product is usable even when the CSS or Javascript fail to load. It requires building products that while that may be single page applications running on Angular, React, or Ember continue to be useful applications when the CDN doesn’t connect or the connection is slow. It means setting a performance budget so that we aren’t trying to load 3 megabytes of data to run a blog. Knowing to reduce images, minify scripts, use CDNs to load things faster, and trying your darndest to limit any single page to something that will load in under 4 seconds and be usable.†

But Why?

Getting back to the disability side of things, recently the DOJ has taken to pushing through that public websites are liable to be accessible to the disabled. There is recent legislation that is forcing airlines to improve their websites. Netflix, Target, H&R Block, and eBay have all been sued by disabled people because their websites weren’t accessible.

You probably have a good idea what a lawsuit brought in federal court would cost your company even before remediation and damages are incurred. Why get sued when you can save money fixing the problems first?

I’m Here to Help

Your competitors haven’t solved this problem yet. Many are in the same boat as you and don’t know where to start.

With over decade of experience in front end development, user experience design, and accessible development I can get you ahead of the curve. Working together we can do a proper assessment of your website in all the major assistive technologies to make certain any deficits are found before you end up in court. With an active assessment done and a remediation plan in place you can resolve many legal actions before they get started.

Once you know where the problems lay, I can work with or train your team on how to resolve those issues bringing your site up to par with WCAG 2.0 AA standards. This is the standard level used by the Canadian, United Kingdom, Australian, and Japanese governments to write their web accessibility legislature. The European Union has used it to craft theirs; and the United States has similar legislation based on WCAG 2.0 AA facing it for a vote.

Contact me to set up a time to discuss your needs so we can set your product or site off as a differentiator in your industry because it is accessible.

† 4 seconds is a magic number that will cause people to think your app is slow. If your customer is using dialup, then a 500kb page will take 1 minute and 13 seconds to download. Sure 3 megabytes is instantaneous on your home cable connection or 4G smartphone, but in the developing world it could be a minute.

Comments closed
Designing with Empathy

Designing with Empathy

Published on October 7, 2015

This weekend I had the pleasure of speaking at the inaugural edition of Open Source & Feelings. It was an amazing conference tackling some really hard topics. I received really great feedback from the audience on my “Designing with Empathy” talk and several asked for the transcript as they couldn’t take notes fast enough. So here is the talk broken out with what was on the slides as well as the script I tried to follow. The video is coming, and I will add that when available.

When I first pitched this talk, I was thinking it was about accessibility because that’s usually what I speak about. As I wrote it. And rewrote it. And rewrote it. It evolved into being something bigger, higher level, and more important than just accessibility. It became about thinking of others and building experiences that we can all be proud of.

Trigger Warning

Some slides contain content that may trigger motion sickness

#DZY

Some of my slides contain motion that could make you feel ill. I’ll give you a warning before they occur.

Empathetic design makes badass users.

Comments closed
Granting the User Control

Granting the User Control

Published on September 1, 2015

More than once I have spoken about giving the user control over their experience. Too often we make assumptions about how things should work, but in the end those assumptions always forget someone. Providing a set of tools for the user to control the situation or experience allows us to have the most rich and dynamic experience we can build, but one that any user can get behind even if they can’t do all the fancy bells and whistles.

One such example is animation in social media. We love (I know I do) to post animated gifs, videos, vines, and cool new web animations in a place where our friends and colleagues can see. For me, many of these (especially videos and animations) will trigger a vertigo attack. The wrong kind of animation could cause someone with photo-sensitive epilepsy to have a seizure. I have a little faith left in humanity and hope no one posts these kinds of things with the intent to harm, but we can do better.

I’m not asking you to stop posting these. Instead I’m asking to give your followers control. If you come across a video full of violence, profanity, or sexual content while at work (or somewhere you would be embarrassed to get caught viewing it), you appreciate when that video has a NSFW (not safe for work) tag on it. We have learned what this means and now have the choice to view it or save it for when we are less likely to be embarrassed if caught.

We also have TW (trigger warning) for articles that contain descriptions of sexual assault, abuse, or suicide. We recognize that some people out there will be dramatically affected if they read these things, so we let them know up front it could happen. They can then choose to keep reading or not. They have the choice and the control.

So, I’m pushing for two new tags. One warns users that the content may cause dizziness, the other warns against possible seizure inducement.

#DZY

DZY, short for dizzy, but a clear concise item that takes up no more than 4 characters (if including the octothorpe – #). It communicates that the following content may cause some vertigo, motion sickness, or dizziness in some users. Putting this in a tweet with a link allows users like myself to decide if they want to click on it. The user has control. They can click through knowing they will see movement (knowing goes a big way in prevention), or if they are having a bad vertigo day (like I am right now) they can avoid it completely.

#SZR

SZR, short for seizure, is the same concept but for things that strobe and flash. Nothing should ever be created in a strobing or flashing manner that riggers epileptic attacks, but if you aren’t sure if it will, you can now warn your followers and users that something is coming that could.

Leave a Comment