Having an accessible website is not only a “good thing to do” nowadays, it is also—in many cases—mandated, where a company must create an accessible website that can be used by people with various types of disabilities (or face consequences).
Until some time ago, accessibility guidelines were governed under Section 508 of the Rehabilitation Act (29 U.S.C. § 794d), or just Section 508. Some companies still think about accessibility requirements in terms of this document (requesting to make their website Section 508 compliant).
However, another set of guidelines took over and expanded on Section 508 requirements, and these are the guidelines which website development teams are expected to follow.
The guidelines in question are WCAG 2.x Level AA. WCAG 2.0 Success Criteria are more explicit than the existing Section 508 Standards—they cover Section 508 and also add some extra accessibility items to the mix.
When Cloudberry builds for accessibility, we always target at least WCAG 2.0 Level AA. And we notify our clients, in case they request Section 508 compliance, about reasons why we’re doing that.
Did you know there’s a risk you can be sued if your site is not accessible? Image source: Fortune.com
With that being said, building for accessibility can be a rather challenging thing to do, especially if you’re just now starting to learn the ropes. Below, we’ll try to outline some of the approaches and considerations Cloudberry uses to build accessible websites.
Accessibility is an integral part of the development process
It might not be immediately clear, especially when you’re just starting your journey into the land of accessible web design, but accessibility is something that needs to be accounted for from the very early stages of development. There are requirements that you need to keep in mind from initial design all the way into actual development.
At Cloudberry, we start working on accessibility from the early stages of design. Primary areas that designers consider are contrast, size of interactive elements and text, and of course the overall structure of content we’re going to present to the user (text flow, headings, lists, etc.).
When the project enters the development stage, we prioritize the following: paying attention to how we approach the building structure of the document, making sure the correct semantic markup is used when creating elements, confirming that the libraries we use in development provide accessibility support (you’d be surprised how many libraries or plugins don’t work in a proper accessible way.) This way, we make sure that all decisions that are being made as we go are not ones we’ll likely regret later.
Of course, you can still address accessibility in a post factum fashion, but in the best case, it’ll cost you another review of all your designs and codebase. And when it comes to the worst-case scenario, you may actually end up having to redo some of the basic work that you have already done (be it design decisions or the selection of your development solutions).
Make sure you always keep accessibility in mind from the very early stages of website design and development.
Little things that matter
It might be a given, but when you work on markup for a website, the tiniest of things can actually have a huge impact on disabled users, but can often be disregarded as, well, tiny, and therefore unimportant.
A couple of examples might be:
- Page titles. Considering that the latest versions of browsers pretty much stopped showing these on a webpage, you may think that page titles (<title>Page title</title> in <head> area of the page) are not that important, and therefore can just be generic. However, for screen reader users, these are pretty much THE indicator and confirmation of the page they are on—whether it be after a redirect from another page, or the result of navigating around the website in other ways. This is the first thing that gets announced by screen reader software, so it’s important that page titles are as descriptive as possible (without going overboard).
- H1 headings. This is another important landmark on a page. Screen-reader users often jump to the first H1 heading in order to get to the primary content of a page. If the first H1 heading on a page has generic, non-descriptive text that isn’t directly related to the page content, it could be confusing for screen-reader users to figure out what’s going on, where they are, and even if they are on the right page to begin with.
- Descriptive links. Again, screen-reader users quite often use their assistive software to extract a list of links on the page and navigate through that list, ignoring whatever other content is on the page. If you markup links on the page as a bunch of “Read more” or “Click here” items, it would not be helpful to the screen-reader users. (Pro tip: if you’d rather not change the link text but would still like to help screen-reader users out, the aria-label or aria-labeledby attributes are your best friends).
Content structure is important
When you look at a webpage with your own eyes, you scan everything in a two-dimensional fashion. You can scan the page from left to right, from top to bottom, even diagonally if you’d like. No problem, well… maybe for you.
However, screen readers are different. Of course, there are many layers of information they can provide to users (such as extracting headings lists or lists of links, etc.), but overall, they are pretty much one-dimensional tools. You can scan a page forward, or you can scan it backwards. But you can’t really jump from a left sidebar to a right side, skipping over content in the middle—you would have to somehow either skip or scan through whatever markup or content is between these page elements.
It is important to structure content on a page in such a way that it makes sense for sequential consumption. A very quick example would be the body of a page, where you would have a sidebar navigation, the text of an article, and some meta information about the article (i.e. the time it takes to read, the author, and share buttons). From a visual design standpoint, you can make it appear however you’d like—sighted users will just figure out that content is in the middle.
However, for users with visual impairments, it’s a different story. How will you order your content in the HTML code? Will it just replicate the visual representation (from left to right—sidebar → content → meta) and most likely make your coding job easier, or will you make decisions based on what is most important for a visually-impaired user to get to first when they’re scanning the page in a sequential order? That’s something for you to decide. It could very well be that you want the sidebar to be reached before the article’s body. However, there’s a good chance that a user would care less about the sidebar or meta information and would want to get to the article’s body as soon as possible.
Again, these types of decisions are best made early on in development, because re-structuring a page after the fact can turn out to be quite time-consuming.
HTML gives you a lot of accessibility features for free
When a screen reader processes the page, it goes over the markup and extracts whatever useful information it finds. Primary elements are various headers, footers, and page areas (like the content area, or a sidebar). It will then use that information to work out a structure of the page and convey that information to the user. This means that a lot of work is done behind the scenes for a web developer, but in order for a computer to get this work done, some—arguably much smaller—work needs to be done by the developer as well.
The primary thing to keep in mind is that HTML5 has various markup elements, such as <header>, <footer>, <main>, <article>, <ul>, <nav>, and so on. All these elements have a special meaning to screen readers, even though you could very well build a page by just using <div> tags. Using the above markup elements conveys to the screen reader that the content inside these elements serves a specific role structure.
High level elements such as <header>, <main>, <footer>, and the like are usually called landmarks, as they specify areas of significance in the document. Other elements, such as <ul>, <p>, <article>, and the like are normally just called syntactic elements, as they specify the type of content they represent.
When a user navigates these elements, both the browser and screen reader already know exactly what their purpose is and how to process them. For example, a <header> is a header, and a <ul> is an unordered list (and the screen reader would even read out how many items are in that list). Additionally, a <button> can be activated by pressing the Enter or Space key, and so on.
Users of a screen reader can specifically jump between landmarks as well as between other sections or elements of the document—and whenever possible, a screen reader will announce items as clearly as it can, and it can usually do that by looking at these tags.
When building a page for accessibility, it is important to maintain semantic markup, since by using that, you provide screen-reader users a very good understanding of the document’s structure and their position within a document, as well as a general outline of what they can do on the page overall.
As a side note, it is absolutely possible to build an accessible page just by using <div> elements. Make sure to add proper roles to all of the elements (and in some cases, back up the required functionality by JavaScript). You can find more information about available roles here if you’d like, and we would suggest that you skim through the list so that you know what you can work with.
That said, some of the roles are not backed up by HTML5 markup, and you would have to use <div> tags or other elements and assign proper roles to them. Examples of such roles could be a tab or tabpanel role.
Overall, the amount of functionality you can get for free is quite insane, really. Make sure you’re aware of the markup tags available to you, as well as their meaning and purpose.
Headings are important
It can’t be overstated how important it is to have the proper heading structure on your webpage (<h1>, <h2>, <h3>, etc.), and not jump heading levels (such as having <h1>, <h2>, and then suddenly jump right to <h4> without having <h3> anywhere).
The reason for that is very simple—headings provide the screen-reader user a high-level overview of the page structure and allow them to navigate “inside” and “outside” of content. If you observe how actual screen-reader users navigate web pages, you’ll see that heading-based navigation is one of the most important approaches for them to understand the page.
Having properly structured content, with logically placed headings, immensely helps visually-impaired users navigate your page.
One of the most common mistakes made is when heading levels are decided by their “look.” Let’s say <h1> is 50px, <h2> is 40px, and the next header is only 16px. It is tempting to markup that next header as <h4> or <h5>, jumping over <h3>—and it even sort of makes sense visually.
However, when a screen reader scans the page, it gets to H1, then navigates deeper into the H2 level of content, and then when it goes even deeper, it suddenly hits H4. The natural result is confusion—”What happened? Did I miss something? Should there be an H3 somewhere or is the page just formatted incorrectly?”
We don’t want to put our users in such a situation, right? So that’s why we should go with a sequential headings structure. No jumping.
Making landmarks and sections easier to figure out
Creating a good structure in the document will get you a long way, but there’s also a little something you can do that will make your users thankful.
Whenever you create a landmark, or a section inside a document (<header>, <nav>, <article>, <section>, etc.), we recommend also adding some extra information explaining what that landmark or section actually contains.
For example, for a navigation menu, you might add an aria-label attribute, like this:
<nav aria-label=”Primary navigation”>…</nav>
In the case of <article>, (or <section> when it makes sense), you can either add the same aria-label attribute as usual, or you can link a readable label to the header of the article. For example, if you have a list of blog posts on a page (each of which should be represented by an <article>), you’ll have something like this:
<article aria-labelledby=’post-1′>
<h2 id=’post-1′>Accessibility is great</h2>
<p>….</p>
</article>
This way, the screen readers will announce your landmarks and sections in more detail, reading not just “navigation” or “article”, but adding their own labels. For example, the above will be read as “Primary navigation. Navigation”, or “Accessibility is great. Article”.
Just some cherries on top of your well-baked accessibility cake.
Custom controls
There are cases when we need to build a very specific kind of interaction between the user and the website—this is often in order to make things easier for the users to understand and act on. There are also cases when existing HTML controls just won’t do the job efficiently, so we have to build custom-made controls to cover such scenarios.
However, this is a double-edged sword. On the one hand, custom controls can make some things easier for most users without disabilities. However, on the other hand, users with disabilities might not be able to access the content at all (at least not in a meaningful way).
You could try and go out of your way by making a custom control which would have good support for accessibility. But, as you can imagine, this won’t be an easy task.
What we are trying to do at Cloudberry is to use browser-provided controls whenever possible. Some of the controls, with enough creativity (and Googling for solutions… right? We do it as well!), can even be customized to a degree you would find hard to believe. An example is a sliding-switch built using just standard HTML elements and styled with CSS.
What to do if you want or need custom controls
There are, of course, situations when you absolutely need to implement custom controls. Often, the easiest way to get them to work is using a third-party library, a jQuery plugin, or something similar.
It is very tempting to just plug whatever looks or feels the best into your code and then be done with it. However, please be very aware of what you decide to use. From our experience, a good chunk of very good-looking plugins and UI libraries, even though they could look great and be very flexible, are not, in reality, accessible. Often, they are almost the opposite of accessible, making navigation for screen-reader users significantly harder (though, luckily, still possible).
From our experience, a good option for building custom controls is the jQuery UI library. The level of accessibility it provides is quite good, though not perfect, and it would save you a good amount of work. However, this is not the alpha and omega of accessible UX components. In some cases, you might want to search for other solutions (usually, something like “accessible accordion” yields some useful results).
On the other hand, it is possible to build simple components yourself. In order to do that, you would need a good understanding of how these components are supposed to work, what roles to assign to which elements, and what kind of keyboard control support you need to add. A good source for such information is MDN’s web docs site in general, and its WAI-ARIA Roles section in particular.
Live areas
As the web becomes more dynamic with content being fetched from the servers on-demand and inserted into pages on request, it makes things much more convenient for end-users, and in many cases, for developers as well.
However, from an accessibility standpoint, adding content to the page after it has already been loaded, (for example, updating text inside an element with content from the server after a user makes a selection), is something that should be considered carefully from a development standpoint. The thing is—for users who have a visual impairment, the fact that content was added to the page after it loaded may be extremely hard to notice. And in a worst-case scenario, the new or updated content will be completely lost on those users.
At the same time, there are certain scenarios where we do need to dynamically update or create content on the page. It could be an alert stating an error during form submission, it could be a new chunk of text that is loaded when a user clicks a button, or it could be a whole screen of content generated when a user takes a survey and screens are neither pre-programmed nor located on separately loaded pages. Luckily, HTML has the means to handle these situations.
The solution to the problem is using another aria attribute—aria-live. Whenever there are updates in a section marked as aria-live, a screen reader announces these changes, choosing the timing based on the importance level of that live area. There are two types of these— “polite” and “assertive” (we’re not counting the “off” state here). We think just by looking at their names makes it rather clear how they work. But you can find more information about live areas on the w3.org site.
We always ensure that when building rich internet applications, we build for users with disabilities as well.
“Keep It Simple, Stupid” (KISS*)
With all the tools at your disposal, such as roles, and aria-* attributes, JavaScript magic, and markup itself, it is relatively easy to try to cover all your bases and end up with a code bloat—also known as second-system syndrome. Don’t let this happen!
The rule should be that everything you build must be as complex as it needs to be, but not more. On the other hand, build everything as simply as possible, but not simpler than that.
What that means is that you should try building your code using available HTML markup elements first, enhancing them with tabindex, role and aria-* attributes, and then further enhancing everything with JavaScript when needed. Don’t go all in, adding roles everywhere, marking every DOM node with some sort of aria-attribute, etc. Over-engineered solutions might look smart, but are not smart in reality. Know when to stop—figuring out when to do so can be difficult to master, but that’s a topic for another time.
Common mistakes and gotchas
We won’t try to boil the ocean – we’ll just cover a few things to look out for:
Tabindex
We mentioned this earlier, but it’s worth reiterating. When building a page, it is rather easy to build it in such a way that the linear structure of the page doesn’t make sense for screen-reader users. In this case, you need to make sure the order of your elements makes sense. You can tune things a bit using tabindex when absolutely needed. However, don’t overuse it—because if you do, you might find yourself in your personal corner of hell.
Hiding elements
When you hide elements—make sure you actually hide them. Use the display: none CSS rule, or mark them with aria-hidden=”true” attribute. If you don’t, (and let’s say, just place an element off-screen), a user can actually focus on the element by tabbing into it (continuously using the TAB key to switch between webpage elements until they get to the ones that are seemingly “hidden,” but not in actuality.
Unless you test specifically for this kind of scenario, it might be pretty hard to notice you even have this issue on your page.
Make sure you deactivate inactive elements
When building pages, and this is especially related to hiding/showing things, such as tab panels or accordions—make sure you properly “deactivate” elements/panels/etc. and remove them from the tab order so a user won’t be able to switch to a hidden tab panel or venture into a hidden accordion section. Use tabindex=”-1″ to prevent elements from being tabbed into and use tabindex=”0″ to get them back. You can also use the standard hide/show approach discussed above, but in many cases, it makes sense to use tabindex.
Bonus tip: play/pause buttons
We won’t tell you to build your own accessible video player all by yourself but imagine a play/pause button scenario in such a player. A user presses the “play” button, and it changes itself to a “pause” button. For a non-visually-impaired user, the situation is pretty clear. However, for screen-reader users, it is actually not that clear. Is that a separate pause button or is that a separate play button or is that one button that just changed itself? For situations like that, you’ll do your users good if you keep the button as “play” and just add the aria-pressed=”true” attribute. Pressed means play is active, and not pressed means it’s not. Simple and easy to figure out, right?
With that, we wave goodbye until next time!
Keep your accessibility tools sharp, and don’t forget you have them in the first place!