Element is Empty

This week I'd like to talk about a couple of different accessibility violations that you may see on your Siteimprove report (or just about any other accessibility tool, as this is very easy to determine programmatically). While there are several ways it may be reported, they all essentially say that the "XX element is empty." This could be headings, sections, containers, or other elements, but in the end, they all roughly mean the same thing—an HTML element that has meaning, but does not have any content within it might be detected by assistive technology.

First, a little bit of background about semantics

Almost all elements in HTML, just by their very inclusion on the page, tell the web browser that they are meaningful. There are two common elements that don't: <div> and <span>. These two elements don't carry any meaning and can be left empty without issue or concern.

All other elements, there are about 140 of them, depending on who you ask, require content within them. Their very presence on the page conveys to the browser that it exists for a reason and, therefore, should have content. For example, an element says that this is a paragraph of content, while an element says that this is a heading of the top level. This can look very different depending on your code, but the most common variation of this violation is simply to have an empty element like these examples:

<h3></h3>
<p><span>&nbsp;</span></p>
<ul></ul>

Most accessibility tools will not flag the <p> being empty as most users of assistive technology will ignore this (technically, it also shouldn't be empty). However, this is quite an issue for headings and other elements because one of the primary ways a user can navigate the page is by jumping directly to headings. So, in the case of that first empty heading above, the user is informed there is a heading, can navigate directly to it, but is then given no information about where they are on the page.

Generally, when you have something like the above, it's a simple solution to delete the offending element within your content management system. However, this issue can be a lot more complex. For example, take the following code:

While it is possible to only have a picture within a heading tag (not always advisable, but permissible in some cases), and it is possible to mark an image decorative using null alt text, when you combine both it makes it so that there is no textual content within the heading. In contrast, this is perfectly acceptable:

Using ARIA role

Just to make things slightly more confusing, ARIA roles may come into play (if you ever edit the HTML). On the one hand, you can add a role to a <div> or <span> that gives the element meaning, such as this:

<div role="heading" aria-level="3"></div>

By adding the role to the <div> you have given meaning to an element that had no meaning. To assistive technology, this is identical to <h3></h3> and therefore must contain content.

This can cause issues in the other direction too. Adding a role of presentation or none to an item removes the semantic meaning of the element, turning a meaningful element into a non-meaningful one like a <div>. Take, for example, the following:

<ol>
    <li role="presentation">List Item 1</li>
    <li role="presentation">List Item 2</li>
    <li role="presentation">List Item 3</li>
</ol>

Here we have an ordered list (<ol>) which is meaningful to assistive technology and should have list items (<li>) within it, but we have added the role of presentation to the list items, so now, according to assistive technology, there are no list items as the meaning has been removed.

So be mindful of any issue that relates to empty containers as the container will be reported to assistive technology.

Siteimprove Weekly: Links are not clearly identifiable

Siteimprove will also flag accessibility issues of "Links are not clearly identifiable." This is for low vision or colorblind users, as opposed to non-visual users. Essentially, you have a link, and nothing indicating that it is a link other than the color of the text. For example, the link I just posted within this blog post is blue on white, but when I mouse over it, the blue changes shades, and it becomes underlined. This is a good link. When there is no hover state, a person may mouse over that content but be unaware that it is a link since nothing changes.

Interestingly enough, the WCAG specifications don't actually say what that hover state should look like, just that there should be one. While you may need help from a developer to mend this issue, it is relatively easy to fix and can be done globally in most cases (one line of CSS is generally all it takes). For example, the following will take a link and make it blue without an underline, then in the hover state will be black with a red background and an underline.

a { color: #00f; text-decoration: none; background-color: inherit; }
a:hover, a:active { color: #000; text-decoration: underline; background-color: #f00; }

While from a stylistic perspective, I wouldn't do the above (it’s a little too much contrast, IMHO), that's the basics of how you do it, and can usually be applied to a single style sheet as a single line (or a couple of different lines if you have different regions that need different looks for the links), and it will fix all your pages.

Note that you don't need to be using Siteimprove to find these issues. Most tools will flag this, but it is also easy to find this on your own by mousing over links in each section of your site. Is it obvious that what you just moused over is a link? Which leads me to...

False positives and negatives

This is an area where false positives and negatives will come into play. It is certainly possible to write a CSS style that would fool the tools into thinking there is a style there for the hover state, such as the following:

a { color: #00f; text-decoration: none; background-color: inherit; }
a:hover, a:active { color: #00f; text-decoration: none; background-color: inherit; }

While there is a hover state, it is precisely the same style as the non-hover state. This may fool different tools into thinking you have done something when in reality, you haven't. The opposite is also true where you could theoretically build a CSS style with appropriate styling, but the automated tools think that you haven't.

So while you should use the tools, also double-check your pages. You don't need to check every page, just every different type of content, which can often be checked by hand on a single page or just a small handful at most.

Siteimprove Weekly: Are these inline frames identical?

Another accessibility violation you may see is "Are these inline frames identical?" Basically, on your page are multiple iFrames (for example, a couple of embedded YouTube videos), and each title attribute is the same. In this case, it is something like <iframe title="YouTube Player" ...=>. In order to be accessible, the title of the iFrame should be unique and directly related to the video. Otherwise, when a screen reader user is navigating, they won't be able to go directly to the video they want. Instead, they would have to play each video to determine which video is the one they are looking for.

In the case of iFrame YouTube videos (which, let's face it, is about 99% of all the iFrames we embed on our pages), I always recommend just doing the title of the video <iframe title="Christmas Fireplace Scene with Crackling Fire Sounds (6 hours)" ...>. This is the easiest and most informative variation. Generally, you don't need to include "YouTube Video" or other indication of what the media is. Just the video title is fine as it will be fairly obvious to screen reader users that there is a video contained within the iFrame.

But now apply this same philosophy to all other elements on your page, such as image ALT text. Do you have two or more images on your page with the same (or very similar) ALT text? For example <img alt="Students in the Quad" .../>. If you have multiple of those on a page, perhaps you need to reconsider the purpose of each image and what meaning it is trying to convey. Make them all unique so that a user knows the difference between them (or more likely in the case where it is a very generic ALT text, make them all decorative).

This same philosophy applies when you have multiple buttons with the same text but do different functions, such as multiple. Make sure that these buttons are unique with an aria-label or other technique such as. However, you don’t need to adjust the text for buttons if every “add to cart” button on the page has the same function.

So, in short, make sure everything on your page is clearly identifiable and not ambiguous to anything else on the page.

Update on Links

Two weeks ago, I wrote about "Siteimprove Weekly: Links are not clearly identifiable" and wanted to update you about that. Someone brought to my attention many results that we both considered to be false positives because there was a clear visual indication on the links. After discussing with Siteimprove, it turns out that in order to pass their checker, you need to have two declarations on any of the link CSS. For example, this does not pass:

a:hover {color: #fff;}

But this does:

a:hover {color: #fff; text-decoration: underline;}

So this is a case where I think Siteimprove is probably being a little over-sensitive with their tool. However, it's an easy fix to get this to go away on all of your reports if this is something that you see. So, add a second visual element to all of the different link states, and this will no longer be an issue.