Your site isn’t accessible
Case study: The Medium homepage
Okay. Maybe it is. But chances are, it’s not. As you’ll see, even if your site scores a 100 on Google’s Lighthouse, it’s likely that there are a lot of factors you’re not considering.
The test
In order to illustrate the ways to properly test your site for accessibility, we’re going to examine the Medium homepage. In theory, this page should be pretty damn accessible since it's a “publishing platform started by one of Twitter’s cofounders 3 years ago, has 25 million users and is worth $400 million” (as of 2015). What we’ll discover is that even a site like this isn’t as accessible as it should be. If that’s the case, I think it's pretty safe to assume that most of your websites aren’t either.
Step 1 — Lighthouse
Let’s first run the site through Lighthouse. I know I just got done telling you that Lighthouse scores aren’t all that meaningful but the hope is that by starting here you’ll see where Lighthouse ultimately falls short.
After running Lighthouse on medium.com the result of the accessibility test is a score of 87. This was actually a bit surprising to me; I was expecting a near-perfect score for a site of this magnitude. Let’s look at the issues identified:
Buttons do not have an accessible name
The issue here is that the buttons in the top right corner of the header will not tell a screen reader what they are. This means that people who have trouble seeing and use an application like Voiceover will have no idea what they are focused on when navigating over these buttons. This is sort of a big deal - some of the main navigation on this site is almost completely inaccessible to blind people!
Links do not have a discernible name
This is mostly pointing out an issue with the Medium logo at the top left corner of the header. Again, when focused on this logo with a tool like Voiceover, people will have no idea what they’re selected on. This logo needs an alt title or aria-label . Just something to identify it to screenreaders.
Background and foreground colors do not have a sufficient contrast ratio.
Take a look at the screenshot above. Look at the numbers next to the articles and the copy highlighted. Both do not have enough contrast. As a result, some people are going to have a difficult time reading that copy.
Heading elements are not in a sequentially-descending order
This is one that can be confusing to a lot of people. Essentially screenreader tools such as Voiceover allow its users to navigate the site by headings (h1-h6). As a result, it is highly recommended that you think of your page as an outline. The complaint here is that the page’s heading hierarchy is all over the place! A well-constructed page from a heading hierarchy point of view should look something like this:
Not like this:
Step 2 — Siteimprove
Lighthouse is cool but it doesn’t cover everything it should. Let’s try out two other tools and see what other accessibility issues they identify. The first is SiteImprove. Siteimprove offers a free Chrome extension. It’s a pretty neat tool & it scans your page much quicker than Lighthouse does. It catches all the same issues and a few others. It breaks the issues up by AAA, AA, and A levels of accessibility, which can help you prioritize.
“Aria-labelledby” has incorrect (ID) reference (72 instances)
This error actually touches on an error that Lighthouse identified with buttons not haveing accessible names. It turns out the issue here is that at one point in time these buttons probably did utilize aria-labelledby to help label the buttons. However, there are 72 instances of this that no longer work because the label ID they were referencing doesn’t exist!
Input field has no description & select box has no description
This is referencing the search input that is revealed when a user clicks the search icon in the header. It’s missing the proper attributes or form tags, which help users on screen readers understand what the input does. From the Siteimprove help text: “Input fields should always have a description that is explicitly associated with the field to make sure that users of assistive technologies will also know what the field is for.”
No option to skip repeated content
It is highly recommended that when building sites with a lot of content we add convenient ways for users to skip past content. This is especially necessary here because the Medium homepage infinitely loads content. As a result, there’s literally no way for a user to navigate into the sticky sidebar with their keyboard!
Link text is too generic in its current context i.e. “Read more”
Generic link text is an important thing to consider for screenreader users because screenreader tools like Voiceover actually allow users to navigate the page by link text. When link text is too generic, like “Read more”, these sorts of users will have no way of understanding what they’re reading more of. It’s recommended to either make links more descriptive OR to utilize an aria-label to override the visual text and assist users using screenreaders.
Step 3 — Wave
Wave is yet another tool to test your page’s level of accessibility. It is also free in the Google Chrome extension store. Like Siteimprove, Wave runs much more quickly than Lighthouse and captures a few different things (including some things that Siteimprove ignores). Here are the unique Wave issues:
Redundant alt text (21 instances)
Alt-text is great and every accessibility tool is going to yell at you to add them to your images, but they can actually be super annoying for screenreader users when used incorrectly. In this case, Wave is letting us know that there are 21 instances of alt text that exactly match the text right next to the image. As a result, when navigating the page with a screen reader, a user is going to hear the same thing over and over in quick succession. The remedy here — make sure your alt text is actually describing the image. It should not just be the same title as the article it’s associated with especially if that title is right next to it.
Redundant link text (62 instances)
Very similar issue here as above. The difference is this is noting links right next to each other that all go to the same place. Check out this example:
The problem here is that the image, title, description, and read more all go to the same place. This is super annoying for people using their keyboard or a similar device to navigate your page. So many extra tabs! Also when viewing all the links on the page using Voiceover, it’s completely useless to see so many things that go to the same place. The recommended fix, if possible, is to group the items like this into a single anchor link.
Step 4 — Manual Test
We’ve looked at 3 tools so far (and there are many more). If Medium, for example, used all of these tools and fixed all the issues that would go a long way toward making their homepage more accessible. Unfortunately, it would still not be enough. The final step is manual testing. This means using your keyboard to actually navigate the page and using a tool like Voiceover. While using your keyboard, you’re mainly looking out for tab index issues. While using a screen reader, I recommend closing your eyes to get a sense of how most people using the tool will actually experience the page. You’ll most likely discover lots of ways to make things better.
Here are some things I found:
Impossible to tab to footer (sidebar) because of infinite loading
We actually covered this one already but it's important enough to mention it again. There needs to be a way to get this part of the site with a keyboard or similar tool. A skip button is probably the best option in this case.
Only one landmark (nav)
Surprisingly it looks like Medium’s homepage is only using a single landmark: nav I’d recommend more using HTML elements like article section header footer and roles like contentinfo and banner Screen readers allow users to jump around the site more easily using these.
Tab order issues in mobile header
Tab through the header on mobile. You’ll see that focus gets lost for a second. Almost definitely due to the hidden search input.
No focus state for notification menu tabs
The notification popup menu’s tabs do not have a focus state. As a result it's really confusing to navigate with a keyboard.
Cannot tab into notification menu on mobile
Clicking and then tabbing into the notification menu works perfectly on the desktop but doesn’t work at all on mobile. This is a reminder to make your site accessible in all viewport sizes.
Cannot see the header at 200% zoom on mobile
It’s actually a requirement that your site is accessible at 200% zoom for all viewport sizes. In this case, the header completely goes off the side of the page when zoomed in this far.
Conclusion
As you can see your site probably isn’t accessible, at least not as much as it should be. These days accessibility is all the rage because people are afraid of lawsuits. As a result, there are a ton of services that offer you quick fixes and scores which help you go back to your boss and say “but it scores 100 on Lighthouse”. Some of these are great and you should definitely be using them but you can’t rely on any one of them. Hell, you can’t even rely on 3 of them. At the end of the day, even after using all the tools available you still have to manually test your site if you really want an accessible page and not just something that probably avoids a lawsuit. Making the web accessible for as many people as possible is much more gratifying than simply doing the bare minimum to satisfy the requirements of the law.
Bonus!
I don’t mean to dog on the Medium homepage. I’ve seen and built MUCH worse. So let me leave you with this really cool accessibility nugget the Medium devs built:
Notice how the menu opens on return, autofocuses you on the first item in the menu and then auto closes when tabbing past the last item and refocuses you on the triggering button.
