That’s it. That’s the tip. WCAG doesn’t round.
… 1 CommentAccessibility, Artist, Music, Philosophy
Category: ADA
I’ll be honest, I often question if I’m evaluating this one right. Let’s look at what the text of 1.4.13:
Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:
- Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
- Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
- Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.
Breaking this down, what does it mean?
I use my mouse or keyboard to focus on a control. When new content is exposed, I need to follow these rules.
Dismissable
I need to allow the user to dismiss this without moving the mouse or keyboard focus. OK, that is clear, but how do we do it? I can’t move the mouse, and I can’t move keyboard focus, then I need another action I can take. This is why we always implement the Escape key to close these exposed layers.
But here’s the trick…
If you hit ESC while one dialog is open, it will close. If you hit ESC while 2 or three are open, they will all close. For single page applications, or modal “sheets,” if users are several levels deep, they go back to the beginning when they hit ESC. You need to keep control of propagation as well as a track of which dialog opened which. As the user hits ESC, we need to stop propagation after closing the dialog. We also need to return focus to the control that opened it.
Hoverable
If I opened the new content with mouse, I also need to move around inside the new content. This does mean that when we are opening it, we are waiting for an exit event before we close it.
Now, that exit event could be a variety of things. Hitting ESC. Mousing over another control that exposes content. Clicking outside the container. The choices are many, but that it is clear how to do it is crucial.
Persistent
The best practice is to use an event tied to a button. This allows the keyboard user to activate the button to open it and close it. This also benefits users who rely on voice control. The mouse user can also open by clicking, or you can add hover to open the area. But mousing out on it’s own won’t close it. That needs another event that is clear the user is done with this object.
For me this is where I always got confused. What does it mean to be persistent? For how long? What if I click somewhere else on the page? Do I have to close the dialog before moving to some other control?
Persistent means once opened, it stays open until you close it. To close it you can do any of the following:
- Escape key
- Close button
- Hover over another active control that exposes content
- Click event elsewhere on the page
- Activating a control inside the exposed content
Best practice: Use at least one in addition to the ESC key.
Have more questions? Want to discuss this? Find me on LinkedIn and BlueSky!
1 Comment
The internet is made for consuming content in two main ways:
- Visually – reading articles, posts, and stories; watching video, short and long form, photographs, and animation
- Audibly – listening to music, speech, screen (via assistive technology)
But the people using the internet don’t all follow the rules and need modifications. One area where we see a lot of modification for customer control is through the text layout. In some cases the issue could be the font, the font weight, or color that makes it difficult to read. Sometimes it’s just the spacing.
1 Comment
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
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
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.
The border is #E1E1E1 and the gray only has a 1.127:1 contrast.
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.
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
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
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
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.
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
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