Skip to content

Category: development

A11y 101: 1.3.2 Meaningful Sequence

The order of consumption of media affects its meaning.

As an 80s kid, I learned that the placement of a comma can change a sentence’s meaning. Of course we learned it through dirty jokes:

  • i helped my uncle jack off a horse
  • I helped my uncle Jack, off a horse.
  • I helped my uncle, jack off a horse.
  • I helped my uncle, Jack, off a horse.

Even the order makes a big difference:

  • I helped my uncle off a horse, Jack.
  • I helped Jack, my uncle, off a horse.

When we write and layout our document, we need to consider the rendered HTML and CSS. We also need to consider the HTML on its own. Some of your users will use tools to absorb the content in different manners.

We need to ensure a meaningful sequences when at the word, sentence, paragraph, article, and component level. We want to develop a meaningful order at the document level also. Usually we do this through landmarks or the use of headings to designate areas of the content. Depending on the relationships of the content, areas could dictate the understanding of the document. So does the header, footer, or main have to follow a certain order? Our instinct is to go header, main, footer. What if our HTML was Main, header, footer and we use CSS to visually move the navigation?

But should we?

Stepping in from the document level, there are things to consider within each component – visual presentation and content presentation. Look at these two cards:

See the Pen 1.3.2 Meaningful Sequence by Nat Tarnoff (@nattarnoff) on CodePen.

Without looking (I saw you look at the HTML tab), you might guess how this is coded. You’d likely think it is Card Title, CTA, image, paragraph, list. And you’d be pretty close. Next you’re thinking, “Ah, image first, that’s how cards are done.”

Both cards have this structure:

<div class="card" id="card1">
    <h2>Card Title</h2>
    <img src="https://placecats.com/millie_neo/300/200" alt="Millie & Neo resting on the cat tree."/>
    <p>Kool kats & kittens at the library!</p>
    <ul>
      <li>Where: Main Street Library</li>
      <li>When: 1pm to 4pm</li>
      <li>Day: Saturday 1/23</li>
    </ul>
    <button type="button">RSVP</button>
  </div>

We can move the content around using CSS. Are the details are more important than the image or the tagline? We try Title, Details, CTA, paragraph, and image. When we are at this stage of developing the code, it’s important to just focus on how the page reads. The two versions of the HTML do not effectively change the meaning of any of the content. Nor do they interfere with the visual display.

How do we fix the meaningful sequence?

We start by looking at individual pieces of content. Let’s start with a button. A button will fire an action, so I need to give it an accessible name to reflect that. I can add a pre-icon, and post-icon, and I know I’ll have at least two states. If I have visible text, then the icons don’t need alt text.

Step two, after styling the most basic of elements, we pair them together. We’re going to use our button to make a search component. This means I need a label, an input, and a way to fire the search. We’re keeping this simple to begin. We’ll use a button and a post action so the page refreshes with results. Most developers will code this label, input, button. But they don’t have to be in that order.

<div class="search-widget">
<input type="search" id="search" aria-labelledby="title"/>
<button id="title" type="submit"><img src="magnifier.png" alt="Search" /></button>
</div>

An easily recognizable or learnable icon can be used as a label as above. We of course provide the alt text. We can use the alt text of the icon in the button as the label for the form. We can change the order visually and it has no effect on how a non-visual user would understand it.

Break up content into the smallest functional pieces. Make sure each piece is understood fully within itself in a meaningful sequence. Then start layering those into the page document in the order to use them. A sales page would have account information first. Then it would include the client’s dashboard. Next, it provides access to individual child accounts. Finally, it lists leads and sales. There is a sidebar to do some research or note taking. We probably have some account screen for the sales person as well. Within each of those sections they’ll have an order that makes sense.

But at a page level the “main” content will be the what the user wants the most. So we put it first. Don’t run away yet. Initially, the order of the main section doesn’t matter. As this user gets used to it, they may want to show and hide different widgets. They might even want to move them. Let’s put a plan in place for that. We don’t want to forget our sidebar, main nav, or account information. These need to be placed in based on order of importance to the user at the code level. When you turn to CSS to position and decorate, is when we get the visual design.

Its always best to do user research on new products. An application like we describe above will benefit from interviewing the potential users. Then within the design, marketing, executive, and client teams conduct some card sorting exercises. Keep repeating this as you develop and design the application. You may find you need to change your design or users didn’t think like you thought they would.

Have more questions? Let’s discuss it over on LinkedIn or BlueSky!

Comments closed

A11y 101: 1.3.1 Info and Relationships

Whenever I come across a a violation of 1.3.1, I have a primal need to look deeper. I investigate because I believe if something falls under this success criterion, it is most likely improperly classified. It is extremely important that we understand the relevant context, information and relationships of content. Frequently, I observe that this particular success criterion is misused. It often serves as a catch-all for “Where does this go?”

So then what does go here?

Per WCAG, 1.3.1 Info and Relationships is:

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Cool. We used the original words to define it. I didn’t like third grade English when I was in third grade.

Let’s look at the intent:

The intent of this Success Criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes. For example, the presentation format changes when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author.

Now this is better. We’re given a breakdown and example. The intent is to ensure that what is visually indicated as structural, explanatory, and informational is available to everyone. This includes people using different presentation formats.

Structural

When talking about structure, it is crucial to distinguish between visual structure and code structure. We need to consider both.

When we look at our mock-up of a page, we want to absorb it visually. Is the most important item in the page grabbing the eye? Does the way it is designed lead you to the next thing you want to say or a primary CTA

(Call to Action)? Take it all in, then we start deciding what HTML elements best represent all those pieces of the page. We begin to think of how we order them. Should it be in a landmark like header, aside, footer, main, or nav? Or is does it need a textual element like headings, anchors, paragraphs, lists, or quotes?

Information

We need to ensure that any information expressed visually is communicated non-visually. If a button is disabled, how do we inform a screen reader user it is disabled? How does a screen reader user know if a Menu is opened? This is the information we should be looking for. In many cases ARIA attributes will be the answers to provide this information.

Relationships

Under relationships we find little programmatic lines connecting the page together. We might specify via aria-label that the first navigation is the “Primary navigation.” Forms point to a more direct relationship in how we set up labels, inputs, and error messages. Using the label’s “for” attribute we build a relationship of the name and input. Aria-describedby with the ID of an error message is another bridge creating a relationship.

Here’s my problem

Much of the time these are not errors of information or relationships. They’re a failure of properly using HTML or ARIA. Sometimes both.

In my example of using the landmarks to construct the basic layout, it isn’t a violation. But we didn’t provide an accessible name. That’s a violation of 4.1.2, so why dump it here?

My disabled button? Case of missing aria-disabled, a 4.1.2 issue.

Headings used out of order? Not a WCAG SC.

Headings not sized to their importance? Now you have a 1.3.1 violation! The visual size provides a hierarchy of importance. On the code side we do this with heading elements H1 – H6.

The Fix

Info and relationships are important on the web. They provide context and details that may not be picked up right away. Anything we do on this account visually needs to be conveyed programmatically too. But that doesn’t mean everything that falls into this bucket belongs. Dumping things in here can harm your clients. You might not provide them enough context to resolve their issues.

Look deeper at the issue. Is it a matter of a screen reader not announcing something? Look at the code, is it missing ARIA? Does it apply to another criteria? Make sure you flag it the right way. And don’t flag it twice, once here and once under the other SC. If it fits under another SC, then fixing it under that criteria will fix it for 1.3.1 as well.

Have a thought, feedback or concern about this article, let’s discuss it on BlueSky or LinkedIn.

Comments closed

A11y 101: 1.2.6 Sign Language (Pre-recorded)

This week we meet our first AAA level success criterion. This put me in a pinch. I had to decide if I wanted this series to include all criteria. Alternatively, it just includes the ones needed to get conformance to current legal standards. And I’m coming out in between. I’ve decided to include only the AAA that should be covered in my opinion.

So this week we’ll look at the needs around Sign Language. We’re still discussing video, but we’re back at pre-recorded video. I will say, if you are holding a webinar, you should have a live sign language interpreter.

Comments closed

A11Y 101: WCAG 1.2.4 Captions (Live)

Nothing 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 closed

A11y 101: 1.2.3 Audio Description or Media Alternative (Prerecorded)

What 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 closed

A11y 101: WCAG 1.2.2 Captions (Prerecorded)

We’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.

Caption Styles

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

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.

Closed Captions

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 closed

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

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

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

Improving Web Accessibility: Quick Solutions

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