Web Accessibility Basics – Focus Outline

This is the second article on my web accessibility basics series. See Web Accessibility – Where to Start to find out more about contrast standards.

Visual Navigation

Have you ever been comfortably navigating your laptop or desktop computer when suddenly your mouse cursor disappears? Maybe it froze or got lost in some black hole off the screen. It is incredibly frustrating because your computer usage comes screeching to an immediate halt. You literally cannot interact with your computer without that little visual indicator of where you are on the screen.

The mouse arrow, pointer, or cursor provides a crucial component of your computer using experience. It is the visual indicator of where exactly you are working in the interface. In websites and applications it provides additional visual queues. The arrow may change to a pointer or finger icon when you are over an interactive element such as a link.

When you are visually navigating and interacting with a computer screen the visual queue provided by the mouse arrow, a blinking cursor, or a pointer makes the difference between a usable and not usable interface.

Visual Navigation Via Keyboard

Now that you know how very crucial it is to have a visual indicator of where you are on your computer screen, imagine that for some reason you are not using a mouse to navigate. There are number of reasons that this might be the case. You may need to use a keyboard to navigate due to a having a limited range of motion in your wrist, or because you have a child in one of your arms. You may be using a screen reader to read the contents of the screen to you and not using the visual interface at all.

In these cases, having functional keyboard navigation is incredibly important. The visible focus state is the keyboard user equivalent of the visible mouse cursor. Keyboard users can use the tab button to jump between links, buttons, inputs, and other interactive elements on the page. So how do they tell exactly what they are interacting with on the screen? They need a visible focus state.

Luckily browsers set visible focus states by default. If you have ever seen that bright blue outline around a link or button (typically a dashed line in internet explorer and firefox) then you are familiar with the visible focus states.

So Where is My Visible Focus State?

Unfortunately, these outlines are often disabled by developers due to design teams disliking them, and in some cases responsive frameworks like Foundation will disable them by default.

You can actually customize your focus outlines in css using the focus pseudo-class.
a:focus {
outline: 1px dashed red;
}
button:focus {
outline: 1px dashed #222;
}
input:focus {
outline: 2px auto blue;
}

The above code applies outlines to their respective html elements on a page.

Set Visible Focus States on All Interactive Elements

You should also have visible focus states on any interactive element on the page. By default focus states are applied to form inputs, buttons, and links (‘a’ tags). For example, if you have a slide out panel, or series of sliding panels like an accordion menu system, then you should have a visible focus state on the element that activates the hidden panel.

It is a good idea to use a button element anytime that you want to have an interactive panel on a page that toggles open and closed – e.g. drop-down panels, accordions, etc.

By default button elements are focusable. Another common method is to us an ‘a’ tag with the href attribute set to “#”. This will create a focusable element for the activating element of your panel.

It is important that interactive elements be focusable by keyboard users, and for the focus state to be visible. That gives your keyboard user a visible queue of what element they are on. Non-focusable elements may not be findable by the keyboard. In other words, your keyboard users may have no way of knowing that an element can be interacted with if you do not use a focusable element, and set a visible focus state to make it clear when that element gets focus.

Additional Resources

In the next article I will discuss how to make your interactive elements activate with the keyboard.

Advertisements

The Unfortunate State of Professional Web Accessibility

Cross posted from medium.

I see it happen on a regular basis, a client insists that their site is “fully accessible” or “fully WCAG 2.0 AA Compliant,” and it isn’t even close, and I don’t mean “they missed a spot,” or that there is some narrow area that I would have personally handled differently. I am referring to giant, obvious, even basic accessibility issues that still exist on the supposedly compliant site. Usually, the culprit is a web-related services company who added “accessibility remediation” to their service offerings without fully understanding what that meant or gaining the necessary expertise.

Let me be clear, any improvement in the accessibility of a site is good, even if the site is far from “fully accessible.” We do not want the perfect to be the enemy of the good. There are, however, a great many companies offering “complete compliance”, “certified compliance”, “certified ADA compliance,” and “certified WCAG 2.0 AA compliance,” that have in reality, chosen to pay attention to only a fraction of the standards that they are claiming to attain.

To state it in another way, if a company is certifying a website as “fully WCAG 2.0 AA compliant” then they should know every WCAG 2.0 AA success criteria inside and out. They should understand the best practices that are recommended by the W3c and by the web accessibility industry. They should be well aware of common failures for every success criteria and how to spot them. They should know the strength and weaknesses of automated testing and when manual testing and QA are needed (which will be something like 70-80% of the work that they do). They should know what it means to get as close as reasonably possible to that conformance level as a site can get. And they should absolutely be aware that while a high level of conformance is possible, perfect conformance is not.

Here are some of the major accessibility failures I see regularly on allegedly “WCAG 2.0 AA certified” websites.

Text Images

No, you may not just use text images wherever you feel like it. Text images are not accessible. They cannot be resized, or restyled for users that have vision or cognitive issues. That is why they are effectively prohibited where they can be recreated via css and actual text. There are a narrow range of exceptions to that rule for items like logos, and depictions of font families. I see this all the time on these supposedly remediated sites — dozens to hundreds of ads and banners that use images of text. Often the developers of these sites do not even attempt to include all of the text from the image in the alternative text attribute, which violates another success criteria.

Contrast

If you do not understand the color contrast requirements, then you are missing one of the most basic accessibility requirements. The problem is that there is a little bit of variation in the contrast requirements based upon the size of the text. Some “accessibility remediation” providers seem to have decided that a 3:1 ratio is all that is needed for all circumstances. Sorry, no. For fonts that are smaller than 24px and not bold the criteria is 4.5:1. If your font is bold that change happens at 18.66px — smaller than that and bold still needs the 4.5:1 ratio.

Pause moving content

Does your content move, rotate, animate, or update, for more than 5 seconds? Then you need a pause button. That means that unless it stops moving entirely and never moves again by the 5 second point, then you should have some sort of pause button that stops the movement. Your auto-rotating banner is entirely non-compliant without this. Your animated flash ad in the sidebar is non-compliant without a pause button. Where is it?

Forms need labels

Yes, there are some exceptions to this rule, but those exceptions are there for circumstances where a label would not provide a benefit, or might make the interface more confusing. You can’t just toss your form input labels because your design team thinks a form looks “cleaner” without them. This is such a basic requirement, that it amazes me how often I see sites that completely neglect this, or use some other technique to try and work around it. Placeholder text is not a replacement for labels or instructions, because placeholder text disappears when you type into its associated input.

Focus States

Have you ever tried to navigate your computer with a mouse after the cursor has disappeared. You can’t do anything, because you can’t figure out where you are on the screen. Focus states are the equivalent of the mouse cursor for keyboard users. If you have disabled focus states or overridden the defaults with something effectively invisible, then you have a site that is not navigable with a keyboard, and hence not accessible. Visible focus states are an explicit WCAG 2.0 AA requirement.

Hidden panels that are not properly hidden

So you are casually using your keyboard to navigate through a website when suddenly your focus state disappears, and then it reappears 40–50 tabs clicks later. It probably just disappeared into a hidden menu that was not fully hidden from the DOM. This happens when developers hide an element by using off screen positioning or some other similar technique rather than “display: none” or “visibility: hidden.” The result is that you just failed the keyboard operability requirement, the visible focus states requirement, and the focus order requirement. It’s like a three-for-one failure, and it really does create a terrible experience for keyboard users.

Look Ma, I beat the automated accessibility checker!

Automated accessibility testing tools are very important, however, they can give you false positive results, false negative results, and they really only cover a small fraction of the accessibility issues that need to be fixed. The vast majority of the issues (75–80%) can only be found via manual testing. But that doesn’t stop less-than-well-trained remediation companies from simply trying to beat a specific accessibility tool, rather than developing a full remediation plan. In the process, they often create problems worse than the ones they are trying to fix.

I have seen sites that put “display: none” on their form labels. This accomplishes nothing. It does not provide readable labels or useful instructions to any of your users. But it does fool some accessibility testing tools.

On another occasion, I saw a site in which the “accessibility remediation company” realized that that css icon fonts (Font Awesome in this case) needed some sort of text inside of a link. Screen readers cannot read css icon fonts, and so when they are used for a link, the developer needs to provide some sort of text to the assistive technology users. The developers at this firm solved the problem by using a span element with “display: none” on it, inside the link. The span had the proper text of the link — the names of the associated social media websites in this case. Unfortunately, assistive technology does not read elements that have “display none” on them. So what did this accomplish? It passed an automated accessibility tool, while not actually providing readable text or a functional link to assistive technology users.

Assistive Tech users are not the only users you are trying to reach

Don’t “screen-reader-only” your skip link. Seriously, don’t do it. Think of all the sighted people with mobility issues that really do not want to tab through all of your navigation. Think of them, please. And while you are at it, labeling inputs in a form actually helps everyone understand what your form is for. Please don’t “screen-reader-only” your labels on anything that is not a super simple, very small (like single input) form. I understand that sometimes you are trying to squeeze a little search box into a small area of a header somewhere, it is already obvious that it is a search box, and that a label could be redundant. But did you really just “screen-reader-only” all of the labels on your “contact us” form? Seriously, don’t do that. For those not familiar with the concept of “screen-reader-only,” there are multiple techniques for visibly hiding an element while making it still readable to screen readers. Sometimes, these techniques are both necessary and appropriate, but like any useful techniques they can be misused and misapplied. Remember to consider how those without assistive technology might be using your site. Users with mobility impairments, but not vision impairments are often forgotten in the push to make a site “screen reader friendly.”

Don’t Forget HTML validation

It’s actually really important that your HTML be parseable. Browsers are very forgiving when it comes to developers using poorly formed code, deprecated code, and even misusing their HTML. If you don’t ever try out the validator, you will never figure out that those <style></style> tags are really only supposed to go in the head of your document, not the body. You might never figure out that your CMS is injecting duplicate ID’s into your page. You might never notice that half the attributes you are using on your tables were deprecated a long time ago. Not every piece of software that attempts to read your page will be as forgiving as a browser, and all of your careful efforts to make your site accessible could be in vain, if it turns out to be non-parseable.

Headings have an order

That’s what the numbers are for. H1, H2, H3… They should go in order. They are not there to satisfy the styling plans of your designer. They should be used in a logical way. Your H1 should be closely related to the title of the page, or be a clone the title itself. Each subheading that is not nested inside of another heading will probably be an h2 at this point, subheadings nested inside of h2’s should be h3’s, etc. There are multiple requirements that relate to this, but the most relevant is likely that the structure of your page should be programmatically determinable. If you are using fake headings like bold font in the place of an actual h tag, or mis-ordering your headings, your page structure will not be understandable to assistive tech users.

Use roles and aria attributes correctly

Semantic HTML elements have implicit roles, you should know what those are. Both aria attributes and roles are meant to be used in specific ways, and have rules for how they are used. Some aria attributes are not allowed on specific html elements. Some areas of your page are considered landmarks, and should have appropriate roles associated with them. Sometimes, remediation firms completely muck this up, and even, on occasion, make up their own roles or aria attributes. Seriously, you can’t just make up your own “aria-stuff”.

The bigger picture

There are so many other issues that are necessary to address to make a website WCAG 2.0 AA compliant — i.e “fully accessible.” The things I listed above are actually the very basic requirements. And when a remediation company has misunderstood, or even completely failed at the basics, then I already presume that they are missing the much more complex issues.

If they can’t figure out contrast or form label requirements, I am going to presume they do not know how to support 200% zoom, or that they have not adequately screen reader tested their sites on IOS devices. They probably never noticed how very inaccessible their mobile menus or accordions are. I am also going to presume that they do not have a clue about how screen readers deal with form input validation, or if their forms are even usable with assistive technology.

Imagine, for example, if every single form on a site was completely unusable to non-sighted users, in spite of the fact that the site was “certified accessible,” because it was using an old inaccessible version of captcha. I have witnessed this on multiple sites, and it is tragic. The owner of the site sincerely believes that they are serving all of their users with a fully accessible site, while entirely failing in one of the most crucial areas.

As developers, we have been misusing and abusing our HTML for years. We have developed and propagated css techniques that fail to consider how both third party software, and assistive technology users will interact with our sites. We have almost entirely neglected the concept of keyboard navigation while designing our desktop sites around the interactive presumptions of mouse and trackpad use. And we have embedded widgets and tools into our sites that block some groups of users entirely from using the services offered by our sites. This is why a deep understanding of website accessibility is crucial to not just those developers that specialize in it, but to all developers who work with the web.

Web Accessibility – Where to Start

Many businesses, when faced with the prospect of making their websites accessible do not know where to start. This post is intended to help with that.

The easiest place to start for most web site designers and administrators is with color contrast. Color contrast refers to the level of contrast the text on your site should have to its background.

There are two primary levels that you should be aware of the 3:1 contrast level for large text, and 4.5:1 contrast for small text. Large text is text that is 24 pixels in height or larger.

A common error is to presume that the 3:1 ratio is good enough for all text across your site. Unfortunately, it is not. Because smaller text is more challenging to read it requires a higher level of contrast to be legible. Small text and this generally includes your standard body text, needs to have a 4.5:1 contrast ratio. In addition, you should never use text, even fine print text on your site that is smaller than 10 pixels.

If you are in doubt whether or not your text should have the 3:1 or 4.5:1 ratio, err on the side of caution and just use the 4.5:1 ratio.

Determining Contrast

There are a number of tools that will check your contrast levels for you. Developers typically use a tool like Webaim’s wave checker to determine the contrast ratios on their site. This comes in a convenient chrome extension. In addition, you can use Webaim’s color contrast checking tool to try out individual colors and backgrounds.

Why is Text Contrast Important?

For a number of years it became somewhat fashionable in website designs to use very faint text, particularly in form fields and in footers. This low contrast text causes major problems for site users who have low visibility. You do want your site visitors to be able to read your content, right? That is why you put the content on your website, right? So give it enough contrast to be legible to the widest range of users possible.