Skip to content

Category: blind

A11y 101: 1.4.11 Non-text Contrast

We previously discussed contrast under Guideline 1.4.3 Contrast. So why is there a second AA criteria for contrast? The earlier guideline covers only text. With the introduction WCAG 2.1, we need to start being aware of the contrast of graphical items, particularly active controls. But the way we test contrast for graphics is different than how we test contrast for text, kind of…

Just as we did in testing text contrast, we’ll need a contrast checker. There are many out there, but for this article I’ll be using Level Access’s Accessible Color Picker. The one you use may be different, but the concepts should be the same.

What does WCAG say?

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

  • User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
  • Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Technical words for technical people. Welcome to the world of writing standards!

“The visual presentation…contrast ratio of … 3:1 against adjacent colors.” Cool. We’re familiar with 3:1, we know how to use the contrast checker, let’s test!

If it were that simple

There is a key phrase here that complicates the testing, “adjacent colors.” Our control must have a 3:1 contrast ratio against adjacent colors. Colors. How often have you tried to make a color palette with three colors that all have a 3:1 ratio? If you haven’t yet, it can be quite difficult. The more colors you add to the palette, the harder it gets.

But this adjacent colors is not expecting you to have a 3:1 contrast between all colors. The second bullet contains important information too. “Parts of graphics required to understand the content…” Of course there is more to it, but let’s start here. We’ll start with a simple button for a disclosure. Let’s get our example from WCAG.

Button to hide the techniques and failures from 1.4.11

This button has blue text on a gray button. The button has a darker gray border and sits on a white background. Most people will test the background color of the button to the white. And that is one way to do it. In this case, it will result in a false positive. First, because there is a border, the gray background is not adjacent to the white. So we measured the wrong thing. We need to compare the border with both the white background and the gray button background. This is because the border defines the edge of the control. This success criterion is about discerning actionable controls.

When we do this test, we find out that neither passes.

Border of #EEEEEE against a background of #E1E1E1 showing a contrast ration of 1.127:1

The border is #E1E1E1 and the gray only has a 1.127:1 contrast.

Border of #E1E1E1 against a background of #FFFFFF showing a contrast ration of 1.308:1

When the border is against white, it only bumps up to 1.308:1. But we’re not done testing this unit. We’ve checked the border against adjacent colors and it fails. But WCAG gave us an out that the W3C is using on their own site. “Parts of graphics required to understand the content…”. What is important to understand the content? Is it the background, the border, or is it something else, say the text of the button.

The text on its own has enough contrast against the gray. No additional graphic is needed to understand the control.

Text color of #1F6DA6 and background of #EEEEEE showing a contrast ratio of 4.768:1

As seen in this image, the blue text against the gray has enough contrast to meet the 1.4.3 Text Contrast rules, and it still supports 1.4.11 despite the background failing.

Summation

When testing 1.4.11 non-text contrast:

  • You need a contrast checker
  • Check the graphic for any borders
  • If there are borders, use the border for the foreground
  • Check colors on both sides of the borders
  • If that fails, check the content of the control
  • If one of the three pass, the control passes this guideline

Thoughts, questions, have a different method? Reach me on LinkedIn and BlueSky to discuss the topic!

1 Comment

A11y 101: 1.4.10 Reflow

We live in a time where our digital device screen sizes vary. We have 1 inch watch screens, phones, tablets, and even TVs with 100 inch screens. We never know what the end use will be using for a device. Reflow is needed to adapt to many of these screens. However, the core of what reflow is about has little to do with screen size. Let’s look at what we really need to know about 1.4.10 Reflow.

320 by 256

Looking at the WCAG Quickref, we see the following:

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

  • Vertical scrolling content at a width equivalent to 320 CSS pixels;
  • Horizontal scrolling content at a height equivalent to 256 CSS pixels;

Except for parts of the content which require two-dimensional layout for usage or meaning.

Reflow talks about having no loss of functionality without having to scroll in two directions on screens as small as 256 pixels wide. It tells us that when the screen is at 256 pixels wide we can have horizontal scrolling, but not vertical. At 320, we can have vertical but not horizontal scrolling.

As a matter of good web principle, it is better to design vertically than horizontally in the majority of cases. For news, reading, and shopping it is easier to consume the content and it is the expected method of scrolling.

But what does it mean if not mobile?

Remember, we are talking about web content accessibility guidelines. For whatever reason, every time I discuss reflow with developers they automatically think it is for mobile devices. And yes, it benefits everyone on any device when implemented correctly. But so does just about everything listed under WCAG (Not all screen reader techniques benefit the able-bodied). And there is a key word that gets left out during those conversations.

Accessibility

This guideline is about making websites more accessible. Reflow wants to ensure that the site does not hide any functionality when any user is on the site. It should not obstruct, obscure, or remove functionality. This includes when that user adjusts their monitor to a different resolution.

A huge number of people on this planet have issues with vision. For most of them, a pair of glasses will correct it. We’re told by our doctors that 20/20 is the most accurate a human can expect. When a person’s vision reaches 20/200 after correction, they are considered legally blind. They have some vision though and decide to increase the resolution on their screen to read it easier. Likely they may not be aware of screen readers yet. Our volunteer here increases his screen resolution to 300% at which he can read it.

When discussing this addition to the guidelines, 1280×1024 was the most dominant screen size for desktops and laptops. There was also thinking that most disabled people are on fixed income and can’t afford current tech. This lead to thinking the disabled to be on older devices.

If we were to increase our zoom from 100% to 400% starting at 1280×1024, the page is rendered at 320×256. If something requires two way scrolling at this point, you need to revisit the reflow rules. We do not want to remove functionality, but it is ok if functionality goes into a menu or disclosure. We want to stack content in the scroll direction.

There are pieces of content that can have horizontal scrolling including carousels and tables. With carousels, ensure the controls are on the screen, but the contents can overflow. You can swipe, but provide buttons for fallback. For tables, ensure the header column is always visible with at least one other full column.

How to test

I’m not writing to a generic audience here. I hope you have deduced a method for testing, but I won’t leave you hanging. Testing is simple, set you browser viewport to 1280 by 1024. Load the page, then use Control/Command and the plus (+) key until you reach 400% zoom. Review the content to ensure nothing is removed. Make sure content is stacked or hidden by disclosures. Ensure there is no horizontal scrolling. You can flip the dimensions for horizontal scrolling sites.

Alternatively, open your developer tools in mobile emulation. You can leave zoom at 100%. Change the viewport to 320×256.

Have some thoughts or more questions on Reflow? Find me on LinkedIn or Bluesky to keep the conversation going.

3 Comments

A11y 101: 1.4.5 Images of Text

I’ve been in developing websites for over twenty years. When I started in the industry, we had to create images of text if we wanted to use a specific font. This was necessary to make things work the way we wanted visually.

The problem of images of text is that screen readers can’t see the text. Like other images we need to provide alt text that reflects the text in the image. It was early in my career, so I tried to find a way to write. I used individual PNGs of letters with the alt text set to that letter. What I didn’t fully understand was assistive technology. My attempted method ended up with the AT announcing each letter. This is because they read each image as a separate unit of text. Spelling my name would be announced as, “N image, A image, T image.” This doesn’t help anyone.

20 years later…

The folks at the W3C’s CSS working group have been working overtime. They have provided us ways to import fonts from CDNs. We have the ability to clip with text. Drop shadows, gradients, transforms provide additional customization.

We also have SVGs. They allow us to put text directly into an image as text. This text is available to AT. This allows us to put stylized text on a path for display.

And…

We do not need to put text in our images anymore. And I’m not referring to logos. That another can of worms. We have multiple ways to add stylized text with unique fonts. We don’t need to use text in images anymore. Just don’t do it.

But…

I know what you are thinking, “My current platform doesn’t allow me to…” or “That requires me to work with IT to make changes and I don’t have many hours…”

There are always constraints. What I described earlier is a best case scenario where all conditions are right to make this problem go away. But that’s not how life works. You will need to use a custom font as an image of text at some point.

And it isn’t difficult. We treat it just like we do with other images. We use alternative text to supplement the image with a text equivalent. In the case of text in an image, that includes all the text.

If you alt text is over 150 characters, I want you to pause. When alt text gets really long it can overwhelm some users. Neuro-typical brains will probably be fine. But neuro-divergent users will have problems. This may be an area where you can break up the image into smaller images. Break the text up to match the images. You can also use figure and figcaption. Here, everything is wrapped in a figure. The alt text is placed on the image. The figcaption contains the rest of the explanatory text.

<figure>
  <img src="https://placekitten.com/200/300" alt="Text in the image." />
  <figcaption>The remainder of the the text described in the image to complete the message needed to express things.</figcaption>
</figure>

And the most important tip I can leave you with is:

Always put sentence ending punctuation at the end of your alt text.

When you don’t use closing punctuation, most AT browser combos will start reading the next item. They will read it as if it were a run-on sentence. This causes added confusion. With the punctuation in place, the AT will pause or announce the punctuation. This is determined by the user’s settings. In either case, the user understands the concepts better without the run-on sentence.

Have some thoughts on this topic? Let’s talk over on LinkedIn and BlueSky!

2 Comments

A11y 101: 1.4.4 Resize Text

Unless you have bionic eyes, at one point or another a computer screen will become difficult to read. For most of us, we’ll reach for glasses or call to make an appointment for an eye exam. But at some point, the glasses just aren’t enough.

I just got my first pair of bifocals. I’ve been using two pairs of glasses – one for distance and one for reading. Before I got the bifocals I had already increased the resolution of my monitor to 125%. All of this to put less strain on my eyes while reading.

And that is the core reason for 1.4.4 Resize Text.

Following WCAG’s QuickRef, we see:

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Without assistive technology our digital assets need to increase their font size to 200%. PDFs you can zoom in on to increase the font size. To test in a browser, press CTRL or CMD and the Plus key. The browser will show you the zoom level as you do this.

Now with the page zoomed to 200%, we need to look for the following:

  • Are any controls hidden or otherwise inaccessible?
  • Is any content cut off?
  • Do I need to scroll in two dimensions?
  • Is the design broken?

You should have no problems if you’ve ensured that your fonts and containers use relative sizing like EM, REM, or percentage. This also includes viewport width or height. Text and containers will resize smoothly.

It’s 2025. Not all applications are feasible on mobile, but we need to rid ourselves of this thinking. It’s 2025 and there are so many screens in the world, we will never know what the user has. We must make our interfaces flexible. Responsive design is not “feature” we add on to be nice. It is a requirement.

Users with low vision don’t start with third-party assistive tech. They start with what they can adjust on their device. When they zoom in from 1280×1024 to 200%, the view should match what is seen on a mobile device. Comparatively, this device would have a 640×512 pixel resolution.

Enjoy this post? Have questions on it? Find me on LinkedIn and BlueSky!

2 Comments

A11y 101: 1.4.1 Use of Color

Color is important. Color allows us to discern whether our fruit is ripe. We use color to control traffic. We spend time in school teaching kids their colors. We ask them to “Identify the red one.” But not all of us see color the same way, and some can’t see it at all. We cannot rely on it to be the sole means of communication.

A little color theory

Light hits an object, and the object applies a filter. This filter absorbs or reflects bands of the light spectrum. The filter is influenced by the materials used to make the object. This could be a pigment, but blue pigment is very rare in nature. When you see blue in animals, it is usually due to the structure not blocking blue light.

The eyes are made up of cones that absorb light. Humans have 3 cones, red, blue, and green. How much light hits each cone type also helps determine the color. Imagine a brand new tennis ball in full light glowing neon yellow. What happens if we cut the light in half? Is it still neon yellow? What if there is just enough light to see the ball? What color is it then?

Or was the tennis ball really neon green? Color blindness is the result of damage to the cones or them not fully developing. There are brain and optical nerve injuries that can cause it as well. To put it short:

My navy blue is not the same as your navy blue.

Trying not to put the horse before Decartes, but our brains are amazing machines. It takes in a extreme volume of stimuli and builds the world around us. While we teach each other a standard that allows us to participate in a society. But when you view blue (or any color), you don’t just get blue light, you get color influence. The colors surrounding your object will change how the colors appear.

These two circles are the same color. But they don’t look like it due to the backgrounds.

Two grey circles of the same color against different backgrounds. One background is pink and the other is purple.

My wife has suffered several strokes and TBIs. We don’t see the same colors. It’s especially noticeable in the transition zones between colors. She asked me to grab something for her, but I couldn’t find it. She told me it was orange. Looking around I thought I found it, but it was red. She swears up and down it is orange. We’ve repeated this discussion with pinks, blues, and greens as well.

We each interpret colors differently. Therefore, it is vitally important that color is not the only way of communicating important information.

Like this article? Then please share. If you want to discuss it, find me on LinkedIn or BlueSky. If you liked my philosophical joke, leave a note and use the “polyphony.”

1 Comment

A11y 101: 1.3.5 Identify Input Purpose

We have four main principles in accessibility: Perceivable, Operable, Understandable, and Robust (Accidentally wrote robot butts first!). The P.O.U.R. principles guide us in how we classify, identify, and fix issues.

When we provide a clear and concise label to an input, we move it from Perceivable to Understandable. Without a clear role, the user will not understand how to interact with it. When we use the same input for the same information in another place on the site, we must keep the naming consistent.

You will often see issues show up under SC 4.1.2 if they flag here. Fortunately, when inputs are named correctly, it resolves both issues. Inputs must have their proper role. Any additional data needed to operate them should be provided. What does this look like? Well it depends on the control type.

Input

The <input> element offers up many alternatives. The default is the type of text. If you forget to include any type, the user will be able to type anything in. You should be familiar by now with radio buttons, checkboxes, and passwords. But we also have more specific versions like search, tel (telephone), URL, range, and color. When you use these native HTML versions, you are provided the the type of input for free. The browser and screen reader both recognize that they are special and behave a different way than type text.

It’s important to note a key point. While I’m discussing the details of the input element itself, the rules mentioned here apply to all active controls.

Labeling

Labeling of an input can be handled multiple ways. The first way you should always attempt looks like this:

<label for="fieldID1">First Name:</label>
<input type="text" id="fieldID1" />

Simple, native HTML. Beyond connecting the label to the field for the screen reader, we assist other users. If a user has issues with their fine motor skills, they don’t need to click on the field alone. The label will place focus in the field. This is super handy for radios and checkboxes due to their size. Further, voice control users will be able to see the label. They can then say “Click First name” and focus will go there.

But this isn’t the only way to do it. If we venture off the above method, we need to make sure we bring the right ARIA along with us.

Auto complete (Optional?)

Along with the ARIA, we want to use autocomplete. The concept of autocomplete has been around for a while. We have browsers that help us save important information. We have password managers the do the same thing more securely. These are wonderful things! They help all users get to the end goal faster. So why doesn’t everyone use autocomplete?

For the majority, it is a security issue. They prevent copy and paste on the input field forcing you to recall the information. But I’m not the first to tell you how hard it is to remember them. Which is why people use the same passwords everywhere and are easy to hack.

One of the ideas about accessibility that people often forget is that accessibility is security. Let’s imagine you are blind and need cash now (J.G. you out there?). You find an ATM, but there is no Braille, no headphone jack, and it is touchscreen only. If the world has been graceful, they are with a confident they can trust with their private information. But if they are solo, who do they ask? Anyone becomes a security threat then.

This same user arrives at work, sits at her desk and boots up the computer. Headphones on, and login, but she isn’t aware that someone has shoulder surfed her password.

Heading back home on the bus, she takes out her phone to buy more dog food online. She tries to input her credit card info. Due to poor labeling, she inputs the card number in the wrong box. She then asks a stranger for help…

When you allow users to paste and use autocomplete on their end, you help those with disabilities. And the security gaps get smaller as the user is more independent.

Have questions or challenges with this topic or my position? Let’s talk them out on LinkedIn or BlueSky!

1 Comment

A11y 101: 1.3.3 Sensory Characteristics

I have a bad habit of saying, “this is easy” or simple. It’ll only take a moment. Like I said, a bad habit that I try hard to break. Why? Just because it is easy to me doesn’t mean it is to you. I was about to start this off with, “This is pretty much straight forward and don’t reference anything requiring senses.”

And I realize, that this isn’t that simple. I’ve been doing this for over two decades as of this writing. Today may be your first day. English may not be your first language. Maybe you can’t relate to the idea of senses.

What do we mean by Sensory Characteristics?

All animals on the planet have the ability to experience their environment. They do this with their senses. Senses are built in detectors to assess our environment. In the accessibility industry, we create solutions. These solutions are for people who may have malfunctioning senses.

When we are little, we are taught about our 5 major senses: Sight, Taste, Touch, Hearing, and Scent. But we also have senses that can detect electrical stimuli, heat, cold, our awareness in space. If you tell someone to find the green button, you’ve violated the success criteria.

So how do we avoid it?

First, we make sure that everything has a proper accessible name. Next, we make sure it unique to the page we are on. It’s super easy to say, “click the submit button” in your instructions if there is only one submit button.

Of course we want to keep the page as simple as possible, so we probably won’t use instructions like that. We wouldn’t say, “click the triangle.” Instead, we should let the construction of the page tell us what to do next.

This looks like first coding the HTML so that if nothing else loads everything is presented and understandable. You can’t position items in a visual order or paint them pretty colors. You also can’t make them do magic. Therefore, we need to rely on the content itself. If your content can’t stand on it’s own, rewrite it.

With the content corrected, we can build out the site. Paint it, position it, then test it. Does it still make senses in the reading order? Focus order?

Lastly, teach the team. Make it an internal standard. Put in monitoring just in case someone makes a mistake.

Want to discuss this more? Come say hi on BlueSky and LinkedIn.

Comments closed

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