Category: Web Content Accessibility Guidelines

Nat standing in front of a shelf filled with toys, gadgets,skulls, and synths they collect. Nat is a white male with a long red and white beard. Nat is wearing a grey Level Access polo for GAAD.

A11y 101: How to test manually

Published on May 15, 2025

Too often, I see companies touting their high accessibility scores. They use tools like aXe Core, Lighthouse, Access Engine, or other free automated tools to derive them. But this only tells a part of the story, and it doesn’t even tell half of it. Let’s explore what is needed, why, and how we go about continuing the testing.

Important Disclosure

I work at Level Access. We have our own toolset that we use internally. While I work there, I try to remain agnostic in talking about tools and techniques.

Tools

Like any project, we need a few tools to help us do the job we’ll need.

Computing Device – This can be a Windows, Mac, iPhone, Android device, tablet, or even Linux. We can’t test websites without accessing them.
Screen reader – This will be device dependent. The Apple products have VoiceOver. Android has Talkback. For Windows, there is Narrator built in, JAWS, and NVDA. I recommend NVDA as it doesn’t lie and is free open source software. I also caution on relying on Narrator. It’s initial use was just to get someone to the point where they can download a “real” screen reader. Microsoft has continued to update it. It is acting more like a screen reader now. However, there’s still work to be done.
Browser – Unless you are working with VoiceOver, the recommended browser to use is Chrome. It has the largest market share and is at the tech edge of production browsers.
Spreadsheet – to log findings. Include columns for at least:
- Finding description
- Finding recommendation
- Page found on (URL)
- Guideline
- Screenshot (I like to use ScreenCast for storing these images.)
- Steps to reproduce
WCAG’s Quickref for the level I am testing against. I test to 2.2 A and AA as my standard.
Mouse
Keyboard (Doing a mobile audit? Use a Bluetooth keyboard without the screen reader.)
Automated tooling – It does help to run automatics at the beginning of an audit. It will reduce the time you spend documenting issues.
Contrast checker
Scope document
Objective of the audit

Setup

We’ve gathered our tools and we are ready to begin testing…or are we? The last two items I mention in the Tools section are a scope and objective. We need to know the objective of the audit. Is it to update their backlog with any accessibility issues? Is it because they need a VPAT? I ask these questions because it influences how I scope.

Scoping is an art to itself. I’ll give a brief overview here. The first part of scoping is understanding the objective and the primary flows.

Look at each primary flow. Are there shared experiences? Yes, we probably only need to test one. Do they use the same header or footer? That can be one unit to test as it is global. Identify patterns used the site and capture them. If pages use templates, say a product details page, capture one of each to test. A thorough audit will likely involve more than 10 pages or units to test. Most of my clients come in around 15-20.

If there is a need for a VPAT, we will add a few more pages. We want to make sure we capture a sample of everything. In the first audit style we may not look at the About Us, Contact, Terms & Conditions, etc. But with a VPAT to be authored, I would be reviewing these as well.

Setup your spreadsheet. I like to make pivot tables and drop downs for key sections. Like which guideline is involved, what disabilities are affected, anything where you will be repeating things from a limited collection.

Step 1 – Mouse

If your vision requires a screen reader, use it instead of the mouse.

Time to start testing. You have your scope. The key here is getting to know the site layout and functionality. Go through every single page in your scope with the mouse and only the mouse. Figure out what items are active controls and how they respond to the mouse.

Step 2 – Automatics

Now that I have familiarized myself with site, I run my automatic testing tools. Depending on the tool you use and how you have it configured, you’ll have a few ways to do this. Some tools look at one page and report findings back in the Chrome Developer tools. If they allow you to export them to a spreadsheet, collect that. You have one for each page tested to compile later. If it doesn’t export, you will need to manually copy them to your spreadsheet.

You may want to roll your own testing bot that can push content to a database. There are several free and open source tooling that will let you run a headless browser with Node.JS to make calls to pages and return the tested output. I’m now playing around with this for a different project.

Automatic tools at best cover 40% of all WCAG criteria. If a company says their AI enhanced tool does better, you may hit 50% coverage. This is because AI doesn’t understand intent, purpose, or how people think into account.

Review every automatic to make sure there are no false positives. Every company out there is saying they get fewer or no false positives. I have yet to find a tool that can honestly say “zero false positives.”

Step 2 – Keyboard

If your vision requires a screen reader, skip this step.

Keyboard testing is based off our mouse testing. We now want to navigate the site like we did in step one without the use of the mouse. We want to ensure that only active controls receive focus. We also check that controls can be used by the keyboard fully in their design. Log anything that doesn’t work properly with keyboard only. Log anything that gets focus, yet is a static element. Caveat – if the link is an in-page link and the target is static a tabindex of -1 is allowable. Repeat this until the page is completely reviewed.

Now you may want to move onto another screen, and that’s fine. Many folks like to go through a project with one tool, then the next. I test my projects by page or screen. So I go through all the steps on a screen, then mark the screen done. You do this as it best works for you.

Step 3 – Screen reader

Pick your screen reader. Remember, these are often device dependent. Repeat Step 2 with the screen reader on. Now, we are determining if the active controls have proper accessible names. Do the names include the visual text? Will they work with the screen reader?

Advice

A control might work with the screen reader off but not with it on. You could be in the wrong mode of the screen reader. There is virtual browse mode. Here the screen reader intercepts all keystrokes as a way to provide faster navigating. This uses Tab to access active controls and arrows to read by line.

There is also a forms mode where the screen reader doesn’t intercept keystrokes. Usually this is invoked by moving into a form field. If it is not, use the screen reader’s hot key plus the space bar will usually change this. In NVDA, this is Insert/Caps Lock + Space bar. Try that widget now. It should work, and if it doesn’t, log it.

Step 4 – Color contrast

Pick your picker! Until you are capable of computing contrast ratios with your own eyes, you will need a color contrast testing tool. There are dozens out there. My favorite is Level Access’s Accessible Color Picker. Before that it was Colour Contrast Analyzer.

Which one matters less than if it is giving you accurate ratios.

Advice

There are multiple contrast ratio methods currently being discussed among the Accessibility Guidelines Working Group (authors of WCAG). We realize there are many color combinations that fail the WCAG standards. However, these combinations are perfectly viable for colorblind and low vision users. One of the calculation methods is called APCA. There is a strong probability it will be used in WCAG 3. However, it is not the standard now, so use a color contrast tool based on the WCAG 2.x algorithm.

Step 5 – Reading level

You need to know the audience of the site or product you are testing. For instance, the targeted audience of this blog is people interested or involved in accessibility work. I have some basic posts, and some more advanced. My language is always meant to be as simple as possible. However, there are specific things I expect others in the domain to understand. One of these is the term WCAG.

Why do we need to know the audience? Because we need to check if the writing on the site is hitting the right audience.

For instance, providing a legal interpretation of a document. If the audience is other lawyers, you use one style. You include as much jargon and as many shortcuts as possible, because you expect them to know the domain.

If the audience is the general layperson, we need to write as if speaking to 13-year-olds. Our language should be clear and simple.

Over a decade ago, I wrote about this for the A11yProject.com. The post is still up and accurate. I’ll relist the resources for testing before the next step.

AI has many great features. One is its ability to identify when text should be simpler. I use it all the time to help clarify my writing. You may be able to use AI-based tools for this. It depends on your access to the admin portion or source code.

Resources:

Step 6 – WCAG SC

When it seems that I have completed my testing, I bring out the WCAG Quickref again. One by one, I read each guideline’s purpose and understanding. For each one, I’ll think through if I might have missed this in my testing. I check each page in scope and log anything I forgot to log earlier.

Follow Up

Now what do you do? Well, this depends on your contract. Good things to do with your client are review the list. Pull out 5-10 of the most important issues. Explain why you pulled them, their impact to users, and how to fix them. Leave them with a priority list of fixes. You could complete a VPAT and issue an ACR. You can work with their team on remediation efforts.

You don’t want to leave the client hanging. Don’t just log 100 or more bugs and walk away. Because next year when they update the product, they’ll need more testing. When they roll out a new product, they will need more testing. Help the client improve through training, fixing, or guiding them.

Don’t do this for free either. When I was independent, I would charge for the evaluation based on scope, not hours. But I’d also put in a recurring monthly support charge. This included 5 – 10 hours monthly paid up front. It is a retainer I take regardless if they use that support. If the time used in a month exceeds the retainer, that gets added to the next invoice. But now we’re entering business practices and that is a different blog post.

Happy Global Accessibility Awareness Day (GAAD)! Have questions or want to discuss this, hit me up on LinkedIn and BlueSky.

A little bonus – Level Access has a lot going on today if you’d like to check out training.

1 Comment

I’m wrong. This is good.

I’m wrong. This is good.

Published on May 12, 2025

I’ve been in the tech industry for over two decades. I’ve worked with Java, PHP, Ruby, JavaScript. I have really strong HTML and CSS skills. I know accessibility and how to manage an accessibility program. I talk weekly with executives and attorneys about their legal risks under ADA, EAA, Section 508, and other standards. I guide them on how to make their program robust to mitigate future legal action. And I’m wrong. Often. And I’m willing to admit it every time.

We are human, we make mistakes

You will make a mistake. Hopefully it is small. But no matter what, it is OK to make mistakes. What matters is how you respond to your mistake. Take ownership. Review your thinking to see what you missed. If you can’t figure it out easily, ask for help.

The number of things I don’t know about in the accessibility space is tremendous.
– Nat Tarnoff

Sometimes the only way to learn something is to fail at it first, or for the 10,000 time. If you fail, own it and work it out. Feel free to fail.

I am not an expert

I’m highly trained. I’m highly observant. I think outside the box. Throw whatever corps-speak you want my way, I don’t care. I learn something every day or I try to. The number of things I don’t know about in the accessibility space is tremendous. I’m not a writer, so I’m still learning about content creation. I’m trying to expand my knowledge and I’m sure I’ll never understand it all. And this is good. It drives me. It gives me space to fail. So when I do fail, I can learn, fix, and grow. And the more work you do, the less you will fail in that field.

Don’t believe the experts

If someone claims to be an expert and knows all the the things, make a tinfoil hat. This person may be highly skilled, but they have a superiority issue and will be hard to work with. They have hardened opinions on techniques. Even if the best advice has moved on, they stick to the old approaches. You have valid questions and ideas. Changing the “expert’s” mind will be challenging if your ideas and feedback challenges their idea of perfect. They will be less willing to look at new research. They’ll take offense to your opinion and suggestions.

How to challenge someone

This isn’t mine, I just learned it Thursday night and love it. Thank Kai Wong for it. The first thing is not call someone out. You call them in. If you see someone make a mistake, take them to the side and let them know. Give them the chance to fix it.

But there are some places we don’t get to call them in. Some platforms have a code of conduct that only allows direct, private messages if you get permission publicly first. In those cases, you may have to call them out.

Like I was the other day. I made a mistake and left part of my thinking out of a response. Someone else in the community asked for clarification. This made me revisit the comment. Turns out they were right. I made a mistake. I admitted it, corrected my meaning and thanked them for challenging me.

Time to get back to work

Keep learning. Challenge the experts. Your input and feedback is important to grow this community. It enhances our understanding of standards. It helps us know where to create new standards and when to throw others out.

Have comments or thoughts on this post, let’s talk about it on LinkedIn or BlueSky.

1 Comment

K.I.S.S. ARIA

K.I.S.S. ARIA

Published on May 5, 2025

Keep It Silly Simple

I sat down to review some code with my colleagues. It was clear that each of these solutions was heavily over-engineered. Each used custom web components, React, Angular, or other framework, and even basic HTML with aria added. All of them should get slimmed down and work to reduce or remove ARIA.

Comments closed

A11y 101: 1.4.11 Non-text Contrast

A11y 101: 1.4.11 Non-text Contrast

Published on April 28, 2025

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.

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.5 Images of Text

A11y 101: 1.4.5 Images of Text

Published on April 14, 2025

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

A11y 101: 1.4.4 Resize Text

Published on April 7, 2025

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.3 Contrast (Minimum)

A11y 101: 1.4.3 Contrast (Minimum)

Published on March 25, 2025

One of the most common issues I see when testing is the content not having enough contrast. With 1.4.3, we’re focus on the contrast of text. This can be text in an image or just on the page. Later we’ll talk about the contrast of active controls in 1.4.11.

Designers commonly complain that they can’t design with the restrictions that WCAG has in place for contrast. At the same time the great designers love restrictions. So your reception will vary when you work with a designer. Remember, they don’t get a choice about adhering to the contrast levels set out.

Defining Contrast

Outlined in WCAG, we have two contrast levels we need to look out for text. We divide text into “normal” or “body” text and “large” text. Body text is all text smaller than 18 point and not bold. If it is bold, it can be as small as 14 point. Everything bigger than that is large text.

This is body text at 14 point.

This is large text, bold at 14 point.

This is large text at 18 point.

1 point does not equal 1 pixel.
1 point is actually 1.3 CSS pixels.

If you are like me, you are looking at those blocks thinking that they don’t look like 14 and 18 pixels. Heck, this body text looks the same size as the 18 point. Well that is because I use a larger than normal font for easier reading. Additionally, 1 point does not equal 1 pixel. 1 point is actually 1.3 CSS pixels. This means 14 point is really 19 rendered pixels. Eighteen point comes out to 24 pixels.

How do we determine what size it is?

In Chrome and Firefox, the web inspector tools offer a “Computed” section. After highlighting the element in the code, switch to the computed tab and look for font-size. This will show the rendered pixel height regardless of what measurement you used to set the size. In addition to points, font sizes can be set with EM, REM, pixel, percentage, viewport height and width, just to name the most common.

Chrome's developer tools opened to the Computed tab. It shows a list of CSS properties and their values, including font-size set to 14.4px.

What are the contrast levels?

Now that we know how to measure our fonts, let’s look at the contrast levels. We have two remember. One for body text and one for large text. For body text, the contrast ratio is 4.5:1. For large text the contrast ratio is 3:1. There are many contrast checkers on the market, so feel free to find one and use it.

My personal favorite is Level Access’s Accessible Color Picker for Chrome. Full disclosure, I currently work for Level Access. However, I’m not pitching the company. This color contrast tester not only provides the contrast and if it passes A, AA, or AAA, but is also helps guide you to fixing the colors.

On the side of the contrast values is a five by five grid. Your picked colors are in the middle. If you move up or down in the grid, options are shown for your background. Moving left or right in the grid changes the foreground. These options may have better contrast.

As a developer using this tool, I look for contrast pairs that don’t work. When I find an issue, I will suggest a color combo from these suggestions that does work. Then the designer just needs to approve, moving the process forward.

What is APCA?

The WCAG is imperfect. It is a volunteer organization of hundreds trying their best to develop accessible rules the majority can agree on. On of the flaws is in the algorithm for finding contrast. There are combos that fall below WCAG standards that are no issue for people with color blindness. There are also combos that meet the criteria, but are unusable because they irritate eyes.

When the efforts to bring WCAG to the next level beyond 2.2, those involved began investigating other contrast algorithms. APCA is one of those. It looks like it will be how we evaluate contrast in the future. However, if you are building a website today it doesn’t matter. The current rules and laws all point back to WCAG 2.x and the algorithm used in that is not APCA. To comply with the current law, you must test colors under the current algorithm. This is true even if you use APCA to choose your colors. If you can use combos that pass both, you are future protecting yourself.

Have questions on this topic? Find me on LinkedIn and BlueSky to chat!

2 Comments

A11y 101: 1.4.2 Audio Control

A11y 101: 1.4.2 Audio Control

Published on March 17, 2025

Along with the <video> element, we also have an <audio> element that works very similarly. However, this particular success criteria isn’t talking about that, at least not exclusively.

Unexpected audio can be quite shocking for users. It doesn’t really matter if the music is a soft ambient melody. It also doesn’t matter if it’s a harsh explosive sound. It can cause issues for the user. For folks who have a sound sensitivity, not being able to control sounds causes problems. This can include persons with ADHD, Autism, hearing issues, vestibular disorders (my personal combo). They may have Hyperacusis (I do), but may not.

Hyperacusis

Hyperacusis is a disorder of the ear where every day sounds can become problematic. According to WebMD, it is considered “rare” at a rate of 1 in 50 thousand people have it. Tinnitus is a symptom, but you can have that without hyperacusis.

Hyperacusis comes in a few varieties. Loudness hyperacusis is a sensitivity that makes your head and ears feel full that can cause migraines. Pain hyperacusis (noxacusis) is a varietal that induces pain and discomfort to the user when the sound is heard. This often feels like stabbing or pins in the ears. Both occur when the volume of the sound is at a level considered “normal” for most people.

In addition to hyperacusis, your user may have a general intolerance to sounds humans often find annoying. These include car alarms, sirens, and barking, to name a few.

Other Disorders

There’s also misophonia and phonophobia. For the most part these are anxiety based reactions that tend to be treated well using CBT style therapy.

Summary

Unexpected sounds can be quite problematic for folks. If the sound plays over 3 seconds it needs to have controls to pause or stop it. Avoid using unexpected sounds. Keep the volume reasonable. And it is always best to tie sounds to user action as it can be less shocking.

Have some thoughts? Want to discuss this further? Find me on Bluesky and LinkedIn to chat!

Comments closed

A11y 101: 1.4.1 Use of Color

A11y 101: 1.4.1 Use of Color

Published on March 10, 2025

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

A11y 101: 1.3.5 Identify Input Purpose

Published on March 3, 2025

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