Skip Navigation Back

Creating a beautiful, easy-to-use, inviting online experience is as much an art as it is a science.  

We strive to build sites that work for a wide variety of people, regardless of their abilities. What we’ve found, though, is that there are certain issues that pop up repeatedly across the internet that make it difficult or impossible for some people to use websites.

In an effort to make sure that the web is accessible for everyone – we’re going to take a look at the ten most common issues we see across the web and how smarter development practices can overcome these issues.  Some are code problems, and some are content issues. Many of the fixes involved can help improve SEO or improve the experience for all your users, not just those with disabilities.

1. Missing or inaccurate alt text

Alt text – important for both accessibility and SEO, is often missing, or is there – but not useful for those using screen readers, or devices that turn website text and images into audio. When alt text is missing, screen reader users will hear that there’s an image on the page but won’t know whether it’s important, like an image of a 40% off sale, or not important at all, like a decorative line across the page. And in general, it’s good practice to describe your image in alt text because if a page on your site doesn’t load correctly, the browser can display the alt text rather than the image.

So how do you write good alt text?  The trick is to keep it short and descriptive; under 125 characters is best. Avoid words like “image of” or “icon of” when writing.  It’s easier than it sounds – a good test is to close your eyes and have someone read the alt text to you – if the alt text describes the image, then it’s good!  

Keyword stuffing, besides being a highly questionable SEO practice,  is not a good idea. Use natural language to describe your images, and stick to what’s in the image. For example, for this image: 

Male frigate bird in flight

 

 

 

 

 

Appropriate alt text might be <alt=”Male frigate bird in flight with an inflated red pouch beneath his beak”>.  This can probably be simplified, but <alt=”flying bird”> isn’t descriptive enough, and <alt=”frigate-bird-flying-primacy-accessibility-ada-compliance.png”> is really unhelpful.

If the image truly is decorative and has no real meaning for the user, you should put it in the CSS rather than the HTML.  If that’s not possible, use null alt text, or <alt=””>, which will cause a screen reader to skip over the image entirely when converting a web page into audio.

2. Hidden focus rings:

If you go to a well-designed site (try the recently launched www.suffolk.edu) and hit the tab key, you’ll see a box that moves along the page with each press of the tab button. This is called the focus ring.  People who don’t use, or are unable to use a mouse depend on this focus ring to navigate sites, so preventing a focus ring and using outline:none is a terrible idea! This hides the focus ring from view, so you’ve now created a new problem where keyboard users can’t track their progress as they navigate through the site.

You want people to click on the CTA? People unable to use the mouse can’t do that if they don’t know when they get to that link.  The solution is simple; design a focus ring that compliments the aesthetic of the page. Make sure it’s visible with a minimum 3:1 color contrast ratio against the various backgrounds on the site.  If that’s not possible, you can invert the colors on the CTA, so the background becomes the foreground. Be creative; have some fun with this and you’ll help all your users, not just those with disabilities. Don’t rely only on color – color-blind users will appreciate it as well.

3. Controls that live beneath the content they uncover:

This is pretty common – you have a block of teaser text, followed by a “read more” button. Once the user clicks “read more”, the button slides down and more copy is exposed to the user.  This is pretty obvious to sighted users, but for anyone who depends on a screen reader, the new copy is challenging to find. Using the natural reading order (scrolling down the page) doesn’t expose the new content – so the user discovers there’s no continuity.  They have to scroll UP to find the new content. Then, the user has to navigate up through the new copy, listening to snippets until they find the end of the old copy. It’s hard to describe in texts, and even harder to do – the entire process is cumbersome and frustrating.

To overcome this, you should make the new content appear beneath the controls so that it’s easy to find in the natural reading order.  Alternatively, your developers can send the focus back up to the first interactive element in the new content.

4. Header Tags:

Designers and developers have gotten into the habit of styling header tags (<h1>, <h2>, <h3>, etc) for aesthetics, rather than for proper page structure.  As a result, content authors may start with an <h1> tag at the top of the page, but beyond that the header tags may be placed randomly based on how the page should look.  While this may not be a problem for sighted users, screen reader users face an enormous obstacle when they first load the page. “Why?” You ask. Many (if not most) screen reader users scan a page’s headings when they first visit a page. Screen readers will read the headings in order, and users can then determine if the page has the information they need. If the headings are out of order, and don’t make logical sense structurally, this makes it difficult for these users to navigate the site and find their information.

What’s the solution? Separate the styling from the heading level – use CSS classes to alter the looks of the headings.  Content authors can then use the <h> tags as they’re meant to be used: to organize the HTML documents in a logical, nested order.

5. ARIA:

ARIA  stands for Accessible Rich Internet Applications, and it’s used to enhance HTML to make the web more accessible. If you’re new to accessibility, you may be under the illusion that ARIA can solve everything – but unfortunately, it doesn’t. Far from it, overusing ARIA can be as bad for users as not using it at all. 

Let’s talk about several ways ARIA is frequently misused:

  1. Landmarks – HTML5 has page landmarks, as does ARIA.  Whenever possible, use the correct HTML landmark rather than the ARIA landmark.  (for example, using <nav> as opposed to <div role=”navigation”> ) If you have more than one of a landmark type on a page, give each one a unique name.  Reserve the landmarks for unique or complex widgets, rather than giving every single module on the page a landmark.  For example, if a CMS widget is a list of links, there’s no reason to make user listen to “region. Link list”. They’ll figure it out pretty quickly as long as it’s a semantically-correct list. So where to use <role=”region”>?  Complex widgets. Carousels, tabs, or any other module with a lot of user-interactions.  This tells the user they have entered a discrete area of the page, with defined interactions.  If your carousels (for example) all work the same, then users will have a much easier time understanding and interacting with that content.  Use your landmarks to define <header>, <contentinfo>, <nav>, <aside>, and <main>.  If there is more than one <nav> element on the page, give each a unique name.
  1. Adding aria-labels to items that don’t need it. If there’s a link on the page with descriptive text, there’s no need to add an aria-label to it as well.

6. ARIA-live areas:

<aria-live> attributes can allow programmers to expose dynamically inserted information.  An aria-live region can have several variations: <aria-live=”polite”> puts the new information into the queue, so when the user finishes their current task the screen reader will announce the aria-live region.  <aria-live=”assertive”>, on the other hand, wipes out the queue and forces the assistive technology to immediately notify the user.

In plain language, updates made to a region with <aria-live=”polite”> will only be announced if the user is not currently doing anything.  Updates made to a region with <aria-live=”assertive”> will be announced immediately, and possibly cancel whatever else the user is doing. In most cases, therefore, <aria-live=”polite”> is the more appropriate use case.

If we examine different types of form validation, we can see where each of these variations may come into play.  For example, if the form uses inline validation, where the errors appear as the user tabs out of a form field, <aria-live=”assertive”> can probably be justified.  However, if the errors appear after hitting the Submit button, using <aria-live=”assertive”> causes the screen reader to announce every error each time the user interacts with the form while trying to fix the errors.  This makes it impossible for users to hear or understand what is happening because of all the noise.

7. Tab Index:

Tab indices seem like an easy way to manage focus.  Resist the temptation! The only <tabindex> values you should use are 0 and -1.  Use <tabindex=”0”> to ensure something goes into its natural tab order, and use <tabindex=”-1”> to take items out of the tab order (you can still put focus on this item programmatically). Using a positive value here defines an explicit tab order – an item with <tabindex=”1”> will always receive keyboard focus before other elements on the page.  The best way to fix the reading order or tab order of the page is to make sure the elements appear in a logical order in the HTML. If your source code is disorganized, restructure the HTML, don’t mess around with positive tabindex values.

8. Focus Management:

Keyboard users are dependent on the focus order following the logical reading order of the page.  Here are some of the most common issues we run into regarding focus management:

  1. Focus does not go into dialogs.  Instead, it stays back on the hidden portion of the page (usually the link that launched the dialog) and the user can’t interact with the dialog content. Focus should go to the first interactive element in a popup.
  2. After interacting with a widget, focus jumps to the top of the page.  Be careful to keep your focus order logical. If you click a button to open a dialog, focus should return to that button when the dialog closes.
  3. Focus should always go top to bottom, left to right, if that is the reading order for the native language of the website’s audience.
  4. Avoid keyboard traps – don’t allow the focus to get stuck in a widget with no way out.

9. Give your users control over their experience:

What does this mean?  Don’t hijack the scroll without warning, don’t autoplay audio/video experiences.  Carousels and sliders need user controls, such as previous/next arrows or play/pause buttons.  If your site has a lot of animated elements, create a toggle at the top of the header that stops the animation and gives the users a simpler, static experience.

10. User proper semantic HTML:

Finally, whenever possible, use the native HTML elements. These have wide browser and screen reader support, and will make a better experience for your users.  The added bonus is that you don’t have to jump through HTML and Javascript hoops to recreate or re-invent accessible behaviors. A great example is buttons vs. links.  If it’s a button, it signals to users that it’s a clickable action on a page – “download,” “sign up,” or “log out,” and also toggle an interface or trigger a popup or modal.  Links drive the user to a new page. Buttons click with a space key, links click with an enter key.  If you code a link as a button, the user may not be able to click on it with a keyboard – so try to use links as links, and buttons as buttons, and be careful not to confuse the two.

By taking these potential roadblocks into account during your design, build, and content population, your site will be far more usable than most websites.  Webaim.org recently found that 98% of the web is inaccessible; by building your site following the guidelines above, you’ll be able to reach that 20% of users who have significant trouble navigating the modern web.

As Forrester Research Analyst Gina Bahwalkar pointed out in a recent report, why walk away from a billion potential customers?

Learn more about Primacy’s Accessibility services here.

avatar
Author: Tyrone Mitchell

Tyrone is a creative technologist at Primacy. With seven years of agency experience and 15 years of web development, Tyrone enjoys bringing a design to life and making a web experience as rich as possible. He speaks HTML, CSS, and JavaScript/jQuery and has worked with brands like Arm & Hammer, American Express, Cessna, Guinness, Trojan, Nair, Filippo Berio, Post, Crown Royal, and Grand Marnier.


Published May 2019

Category Accessibility

Comments