Making Umbraco ATAG and WCAG-compatible

At Perplex we’ve been working on accessibility for years. We believe that everyone should be able to use any site in whatever way they wish. We have received the official certificate (the Dutch office responsible for testing accessible websites) for several of our sites and want to continue doing our best to contribute to a better web for everyone. Last spring, we decided to test Umbraco against the WCAG and ATAG guidelines by an official Dutch testing organization. An accessible website is nice and all, but doesn’t the backend need to be just as accessible?

“Sure, having a visually impaired maintain a website in Umbraco is an edge case. But why is that? Shouldn’t everyone be able to create a website in Umbraco?”

A few months ago we asked the Dutch office responsible for the stamp (Foundation Accessibility) to test the current Umbraco-version (Umbraco 7.6.2 at that moment), in combination with our own Perplex-starter package. This baseline-check was already met with very positive results. Already 31 out of the 38 WCAG-accessibility-tests were passed.

During the latest Umbraco Retreat our colleague Jeffrey, together with Mads from Umbraco HQ, dedicated some time and effort to the remaining issues. Our goal is to make sure Umbraco will fully comply with all accessibility rules and guidelines, and thus making Umbraco WCAG and ATAG-compliant. In our opinion it would be huge benefit if Umbraco is WCAG-compliant and giving organizations that are implementing Umbraco a small benefit when pitching against other Content Management Systems.

In this blog item, we will go over the the seven remaining issues that should be solved to make Umbraco compliant. We will explain what the exact problem is and offer a possible solution. We will also link to the relevant WCAG-specification and the issues that is created on the Umbraco Issue tracker. If you think the issue is relevant too, I'll hope you vote up the issue.

In a subsequent blog we will explain what work has been done during the retreat and what we could be doing in the near future.

An example of correct implementing guideline 1.1.1. Non-text content

1.1.1 Non-text Content

Guideline: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. 
WCAG Specifications | Umbraco Issue 10207

Description: All images and icons need an alternative text that can be presented to, and interpreted by, screen readers. This will allow the visually impaired visitor to understand the meaning of the image. With regular images, this is done by simply adding an ‘alt’ attribute to the tag. Icons however, are often added as a background-image or icon-font. To make sure these are readable by screen readers, add a hidden text that describes the icon.

Umbraco: Within Umbraco, there are many icons each with a different function such as displaying the status of a node or its type. When you see a tiny, little house in front of one of your Umbraco-nodes, you understand this is probably the homepage. For someone using a screen reader however, this is not clear at all. By adding a description, this user will now also be able to understand what the icon is trying to convey. This could simply be done by rendering some additional html in the tree that is not visible to anyone, except for screenreaders who can read it.

If you look at the html in the above example you see it should be a quick fix (for the tree).

An example where the sequence of the HTML in code is not meaningful, thus violating the guideline.

1.3.2 Meaningful Sequence

Guideline: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. 
WCAG Specifications | Umbraco Issue 10209

Description: The order of your HTML should be equal to order in which this is visible for your users. It can be very confusing or disorientating for a user when the content is being read to him in the wrong order.

Umbraco: An example within Umbraco is the overlay that is shown after selecting the profile options. Because the overlay doesn’t directly follow the button in the DOM, it’s difficult to reach with the keyboard and users using a screen reader won’t understand what happened on the screen after selecting the option.

2.1.1 Keyboard

Guideline: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
WCAG Specifications | Fixed in Issue 9991 (please vote up, to get it merged in)

Description: Allowing full navigation of your site with just the keyboard is one of the most important aspects of accessibility. Both for the motor- and visually impaired users navigate using their keyboards. As such, it is important that all elements within a page are both accessible and controllable with a keyboard. Actions such as selecting, moving or scaling should all be possible without even touching the mouse.

Using the tab key, the user will move across the page in a logical order. By hitting enter, a link is clicked. It is of equal importance to be able to close any overlays that are opened with the escape key. Navigation and tabs should also be controllable with the arrow keys and buttons and other input elements should be selectable with the spacebar.

Umbraco: The biggest hurdle within Umbraco, is the fact the content tree can’t be controlled with just the keyboard. This is because many links within the tree, aren’t actual links. Buttons, input fields and links with a href attribute automatically receive focus out of the box. The “links” in the content tree used to show the node-options or expand the tree however, work without href as they use an Angular click event.

This issue was worked on during the Umbraco Retreat and a Pull Request was created. Unfortunately the functionality is not merged in yet. If you would like to play around with a keyboard navigatable Umbraco-version you could check out this site; (login: test, password: test).

An example of implementing skiplinks / bypass blockers (guideline 2.4.1.)

2.4.1 Bypass Blocks

Guideline: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
WCAG Specifications | Fixed in Umbraco Issue 9991

Description: By adding so called ‘skiplinks’ it is easier for users to skip parts of your page or to jump to a specific section within the page. Because pages within a website or application are often structured in the exact same way across all pages, it can be nice to skip those content blocks that appear on each of them. By skipping parts of the page, the user can jump straight to the actual content.

Regular users won’t see the skiplinks and they aren’t shown until given focus. By placing these links at the top of your HTML, they will be the first thing a keyboard user sees when he starts navigating.

Umbraco: Within every page of Umbraco, it should be possible to use these links to navigate to the most important content. This way, the content can be seen swiftly. Furthermore, an extra skiplink to the content-tree could be added to easily jump back to the content-tree. Currently, the user has to tab through the entire navigation, searchbar and content-tree to get to the area of the page where he can edit his node.

This issue was worked on during the Umbraco Retreat and a Pull Request was created. Unfortunately the functionality is not merged in yet. The skiplinks are implemented in the solution, and when navigating throught the links in the page, the skiplinks will be presented first to go directly to the searchbox, the content tree, or the content. You could see this in action in this website; (login: test, password: test).

2.4.3 Focus Order

Guideline: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. WCAG Specifications | Fixed in Umbraco Issue 9991

The focus within a page shows where the user is currently at and which button or link is selected. The order in which these elements can be focussed needs to be logical to prevent the focus from just bouncing around the page at random.

But, just a good, logical order isn't always enough. If we take a pop-up that's opened when clicking a button for example, the focus will need to jump to the contents of the pop-up. The user can then continue navigating inside this element. The focus of elements outside the pop-up should be disabled until the pop-up is closed. This way the tab order is logical and users won't get lost when navigating with their keyboard or screen reader.

Umbraco: There's still some room for improvement for Umbraco within this area. Interface elements, like tabs, need to easy to use and accessible. When selecting an item the focus should move to the content of the chosen tab, allowing the user to immediately select it.

This issue was worked on during the Umbraco Retreat and a Pull Request was created. If you tab through the solution, you will navigate logically from one element to another. Probably it will needs some finetuning in a next Pull Request, but probably 90% of the work is done.  You could test this in this website by tabbing through Umbraco; (login: test, password: test).

2.4.7 Focus Visible

Guideline: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
WCAG Specifications | Fixed in Umbraco Issue 9991

Description: The focus within a page should always be visible and should clearly indicate where the user is at. This can be checked very easily. Simply use the tab key to navigate and check if your focus is still visible after every click.

You can add styling to the focus by adding the :focus selector in your CSS, it's that simple. With this you can also adjust the standard focus (a thin, blue line) of the browser. Just make sure that the default focus isn't removed completely.

Umbraco: In Umbraco, the nodes in the content-tree and the tabs on top of the pages have the focus style removed. This makes it impossible for the user to see which tab he has currently selected and making it nearly impossible to navigate.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus nec lorem a felis gravida dictum.

4.1.2 Name, Role, Value

Guideline: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. WCAG Specifications | Umbraco Issue 10208

Description: For users that are unable to see the content on a page, it is important to understand how certain elements work or should be used. Using the right HTML-elements is essential to assist in this. By giving your inputs a nice, descriptive label they too can understand what is expected of them. If a specific format is required or when the field isn't optional, like is often the case with a date field for example, it needs to be made abundantly clear.

Inside web interfaces, like Umbraco, the proper use of HTML alone isn't enough. Pages contain specific tasks that can be executed or have elements with a certain status. The help with this, ARIA (Accessible Rich Internet Application) was developed.

ARIA makes it possible to give (parts of) pages an extra layer of information, something that's not possible with just HTML. These could be a role, property or status attribute that is assigned to elements on a page. Using this, you can transform a list into a menu by adding [role="menu"] and by adding [aria-haspopup="true"] you can show the menu item has a submenu. Aside from that, you can decorate an item with properties like [aria-expanded="false"] to signal whether or not an item is currently folded out as well as adding a name or title with [ aria-labelledby].

But, hidden texts also work to have your status and title read to the user. You don't specifically need ARIA for this. Since it's a relatively new technology, only the latest screen readers support it. So for now, the hidden text option is a valid alternative.

Umbraco: Within Umbraco relatively little attention had been given to assigning roles and statuses to elements within the interface. Most statuses (active or disabled) only have a visual indicator and thus are invisible to screen readers.

In our opinion, these issues shouldn't be much of a problem to tackle and most of the issues is already a fix for. So by giving a little extra love, we can make sure that Umbraco can update its slogan from "The Friendly CMS" to "The Friendly CMS, for everyone"

Our next blog will be about the work that has been done to accomplish this goal.

Questions or ideas? We love to hear them! Interested in making your site accessible to all? Contact us.

Read more

Personalizing an Umbraco website