As a Web Accessibility Specialist (WAS) I tend to view things through a specific lens. I silently evaluate every site I visit for accessibility. It is similar to how someone might notice ceiling tiles that are not aligned correctly or picture frames that are not level. Due to the WAS lens through which I view the web, any work I do or check for Reaktiv goes through my internal accessibility filter.
Clients often make requests for features that are not inherently accessible. As soon as I read these requests my gut tells me “no!” Then I start thinking about the important question, “how can I accommodate these requests while keeping a high standard of accessibility?”
Is this an Inaccessible Request?
Recently we were tasked with adding a cookie compliance banner to a site. The client has multiple sites, and some are EU-specific so they already have a banner. This site was more global in nature, so we needed to load the banner only for EU visitors. We encountered several issues that dictated a different approach than the sites that always loaded the banner.
Another requirement was to make the new site banner look the same as the EU-specific sites’ banners. Much of this was possible with custom CSS, but the load behavior of the new banner was different from the old banner.
In order to make the banner more accessible, the new banner loads with a focus trap. This behaves like a modal and ensures that keyboard users are able to access the banner and make a decision.
An Accessibility Issue
The only issue is that it loads the banner and makes the first link “in focus.” This resulted in the first link having a visible focus indicator.
The visual focus indicator is a WCAG requirement that adds a way to identify where the current focus is on the page. The main user who needs this is someone who is sighted and navigating the page with a keyboard. Usually the focus indicator appears as a box around the element that is currently in focus.
While there are many reasons a user who can see the screen might choose to use a keyboard to navigate the page, one of the main user stories involves someone with mobile disabilities like a hand tremor. In this case the person finds it difficult or even impossible to use a mouse but is able to use the keyboard.
For this user, a visible focus indicator is very important so they know where they are on the page.
In our case the client liked the banner but wanted to remove the focus indicator for aesthetic reasons. The old site loaded without a visible focus because it didn’t create the focus trap. The new banner matched the old banner almost exactly except for this one difference.
The client asked to either remove the focus indicator or set it to the same color as the background. Both of these options would have made the banner inaccessible because sighted keyboard users would never know they were on the link.
Rethinking the Accessible Solution
My first instinct was to try and educate the client on the importance of the visible focus indicator. Early in the conversation I explained what the box around the link was and why it was important. This led to the request to make it the same color as the background.
At this point I could have tried to better explain why this was a bad idea and why the focus was mandatory. This isn’t really a great strategy with clients because we are hired to be experts and solve problems.
Rather than solve the problem, I was trying to make our client an accessibility expert. That isn’t what the client wants or needs. They want the banner to look the same and the initial focus state doesn’t look the same. Any training just comes across as “I don’t hear what you are saying.”
Taking a step back
Instead, I took a step back and asked how I can make this behave more similarly. How can I preserve the focus indicator but not show it in focus on the initial page load.
I went back to the original site and noticed I had to push tab twice to get to the banner. When the page loaded there was nothing in focus. This is true of most sites. You have to press tab to select the first element on the page.
What the client wanted was to have a similar experience with the new, more accessible banner.
The Solution
After some tinkering I came up with a solution that caused the focus state to be hidden initially. When the page loads it looks like nothing is in focus, which is the state keyboard and mouse users expect.
Then after the tab key is pressed for the first time, a small script activates. This script removes the class that hid the focus state and then turns itself off because it doesn’t need to keep running for subsequent tab key presses. The end result was achieving the client goal of having a banner that looked the same as the original while maintaining a dedication to accessibility.
Experts Who Care
At Reaktiv, we are experts who care. We strive to go above and beyond for our clients by helping them meet their goals while ensuring their sites are usable by all visitors. Contact us now if you are ready to work with a team of experts who care about not only your goals but also the needs of your customers and building a better, more accessible web.
