In the beginning, there was only the command line.
Xerox and Apple brought us a graphical user interface (GUI)and the mouse. A small handheld tool to help you move across the GUI and interact with the objects on it. But we still had the keyboard. As time wore on, people forgot about the keyboard more and more.
… 1 CommentThat’s it. That’s the tip. WCAG doesn’t round.
… 1 CommentI’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.
I use my mouse or keyboard to focus on a control. When new content is exposed, I need to follow these rules.
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.
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.
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.
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:
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 CommentMany of the auto scanning tools on the market will flag for suspicious text on links and buttons. Sometimes the settings for that tool will flag long alternative text as well. Some look at short lengths. We flag character length because we can’t verify the item makes sense in context. This is something computers cannot do. Even with the best AI out there, computers can’t detect the intention of the control.
Comments closedThe internet is made for consuming content in two main ways:
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 CommentToo 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.
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.
Like any project, we need a few tools to help us do the job we’ll need.
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.
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.
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.”
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.
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?
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.
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.
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.
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.
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.
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 CommentI’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.
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’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.
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.
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.
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 CommentKeep 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 closedWe 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.
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!
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.
When testing 1.4.11 non-text contrast:
Thoughts, questions, have a different method? Reach me on LinkedIn and BlueSky to discuss the topic!
1 CommentWe 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.
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.
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.
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.
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
