Taking a Step Back – What is Accessibility?

Accessibility is always  a large concern when creating applications. Whether these are meant for the web, desktop machines, or even mobile devices, accessibility is a huge factor. I have often run into scenarios where developers are not even aware of accessibility concerns, or decide to leave it as one of those “oh, I’ll get to it later” tasks on their TODO list. Some of you might even be asking yourself what accessibility actually is. Well, when I talk about accessibility I’m referring to the ability for your application to function for people with disabilities so they can still navigate and interact with your application.

If you haven’t taken a look at the accessibility of your applications you should really dedicate some time to ensure that your website complies with modern day accessibility guidelines. Some of the more popular ones are Section 508 (used a lot with government organizations) and the Web Content Accessibility Guidelines (WCAG) 2.0. Here at Telerik we pride ourselves in complying with these two, as can be seen on this page.

Now today I want to talk about another set of guidelines for accessibility, WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications). This specification goes over how to increase accessibility of web pages where dynamic content and user interface components have been implemented using Ajax, HTML, CSS, JavaScript and other technologies. Essentially a guide on how to ensure that today’s websites can be as accessible as possible.

Along with introducing WAI-ARIA I want to take a look at how VS11 can help us with developing more compliant site, as well as what we here at Telerik are doing in this area.

If you want to take advantage of the cool stuff that Visual Studio 11 is doing with WAI-ARIA I recommend that you download the VS11 beta, which you can find by clicking on the following image :)

Get the Visual Studio 11 Beta!

What is WAI-ARIA?

So, what is this whole WAI-ARIA business? Well, as I mentioned above WAI-ARIA is a set of specifications on how to increase the accessibility of modern day web applications that deal with “dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies” (quoting the official WAI-ARIA page here). This comes from the Web Accessibility Initiative (WAI) of the W3C.

What it boils down to is that ARIA is a set of additional semantic tags and attributes that describe and identify features for user interaction, how they relate to each other, and their current state. Often times this boils down to their roles, states, and functionality. Think of controls such as menus, trees, and grids. All of these are pretty sophisticated controls that have a lot of dynamic-ness surrounding them.

Although it is a fairly new standard it still has gained support across most of the major browsers. To name some, IE8+, FireFox 3+ and Chrome 4+ (although in Chrome this is still partially supported) all support the standard (although some a bit more than others). Support also increases with each new version of these browsers. For detailed list of what browsers support WAI-ARIA you can check out the caniuse page right here.

Why is WAI-ARIA Important?

All the good stuff you’re using today to get the awesome interactions and behavior out of your site takes heavy use of the technologies that WAI-ARIA covers; HTML, JavaScript and Ajax. Implementing these can often lead to confusion within the technologies and applications that are used by people with disabilities, with screen readers being the most common types of applications used.

These screen readers attempt to read the content of what is on the user’s screen out loud to the user, by parsing through what the browser is displaying and presenting that to the user. Remember that application you wrote that had ridiculously complicated HTML, followed by a couple of thousand lines of JavaScript to deal with interaction? Imagine an application attempting to parse through that and tell a human at the other end what it’s seeing, in terms that are understandable. All of a sudden that paragraph that comes flying in from the left and constantly moves around the screen seems a little bit over the top, right? Well, it probably should feel over the top either way ;)

WAI-ARIA is here to make it easier for people with disabilities to access your website. This means that not only can you provide your content to everyone, you also equalize the playing field of the awesome place that is the internet.


So, how does Visual Studio 11 help you with ensuring that your application is more WAI-ARIA compliant? Well, it makes it ridiculously easy to include it by using intellisense of course! I personally love intellisense because I constantly doubt if I spelled something correctly. Plus, if I’m unsure of what’s available to me it’s very easy to scroll through the options that I have and find which one fits the best for me.


Let’s take a quick look at how I would go about defining a menu in HTML and how WAI-ARIA can get implemented:


<div id=”menu”>
      <li class=”menuItem”>Menu Item 1</li>
      <li class=”menuItem”>Menu Item 2</li>

The example above assumes I have some awesome CSS to go along with it to make these items menu-like. Now that I think about it, let’s make this HTML5 compliant :)


<nav id=”menu”>
      <li class=”menuItem”>Menu Item 1</li>
      <li class=”menuItem”>Menu Item 2</li>

Side-note: Always try to find a good excuse for working in HTML5!

Now if a screen reader were to go through here and see this, how does it really know that this is a menu? Sure, “Menu Item 1” and “Menu Item 2” and even the CSS classes and ID attribute gives it away, but I could be very sneaky and name this something that the screen reader wouldn't parse as a menu. You could end up with some very odd statements being read back to the user. This is where WAI-ARIA comes in and solves the issue for us. Let’s WAI-ARIA-ize (newly coined term right there!) the code above:


<nav role=”menu”>
      <li role=”menuitem”>Menu Item 1</li>
      <li role=”menuitem”>Menu Item 2</li>

Imagine you were to write a screen reader. Wouldn’t this latest code snippet just make your life so much easier? Now we know that the parent nav element is supposed to be a menu, and the list items we have are menu items! Now how did VS11 help me with this? Intellisense! Take a look at this screenshot to see how helpful it was for me:

WAI-ARIA role intellisense in VS11

Right after I typed “role” and hit the “=” key I immediately got a list of available roles.

States and aria-*

So that was roles, but what about various states? When I talk about states I literally mean the state of the element. If, for example, we were creating a tree view, wouldn't we want to know if the current node is expanded or collapsed? This is where ARIA states come in to play. These are dynamic properties, so they change along with the state of the element. These are often handled by using attributes that are prefixed with “aria-“. VS11 is nice enough to allow us to have these available in intellisense! Let’s take a quick look at an example of how to use some of these attributes.

What I’m going to do is add a very simple aria-* tag to an input, namely aria-required. This labels the particular element as a required field for all of the screen readers out there. Now, you might be thinking “We already have that! Just add the error message or a ‘*’ next to the element!” Well, I’ve seen plenty of examples of some neat an intuitive ways to display required field messages, but they’re not always that easy to see for screen readers. For example, what about just bolding the label that is tied to an input field? Pretty easy to spot by a human, but difficult to parse through with a screen reader. The aria-required tag makes it super easy to say that this field is indeed required. So, I’ll just start off by creating a label and an input:


<label id=”firstLabel”>First Name</label>
<input id=”firstName” type=”text” />

Now if I want to add the appropriate WAI-ARIA tag to this I can of course just look up the various ARIA attributes and their accepted settings over at dev.w3.org, or I can use Visual Studio 11. As you can see in this screenshot, when I type out aria- I get a whole list of potential attributes I can set just via intellisense

WAI-ARIA attribute support VS11

VS11’s intellisene even provides us with the appropriate options available to us

WAI-ARIA attribute support VS11 options

It even works with ARIA attributes that has multiple options

WAI-ARIA support in VS11 more options

Pretty neat, eh? Useful as well! With it being this easy to add accessibility to your applications there really shouldn’t be anything stopping you from implementing this!

Telerik and WAI-ARIA

Because I’m proud of Telerik’s efforts in this area, I wanted to write a quick note about the WAI-ARIA support that we offer in Telerik's controls for ASP.NET AJAX. Although not all controls currently offer this support, we do have it enabled in some of our bigger ones like Grid and Window. This list is also constantly expanding, with all recent releases expanding on this availability.

How do you take use of this in the supported controls? Well there should be a simple property called EnableAriaSupport which you should just set to true. This will allow the control to go from the “regular” mode into a WAI-ARIA compliant mode that renders ARIA roles and states.

For an example of this support, and the difference it makes in terms of the HTML, you can check out this blog post which goes into further details about the RadGrid’s WAI-ARIA support.

Accessibility-rize Today!

I just love making up words! Anyway, hopefully I was able to enlighten you a bit on what WAI-ARIA is, and why it is important to think about when creating your new application, or going through and modernizing an old project. With deeper browser support happening with each release of our favorite browsers, and tools like VS11 to help us out when we either forget to implement it, or what roles and states exist, it becomes even easier to make an amazing web application with the latest and greatest standard, while still allowing all your visitors to see the content.

Try the Telerik RadControls Today!

Carl Bergenhem
About the Author

Carl Bergenhem

Carl Bergenhem is the Product Manager for Kendo UI. Throughout his time at Telerik/Progress he has covered the entire portfolio of products offered, but mainly spent his time in the web development arena covering ASP.NET Ajax, ASP.NET MVC, and JavaScript-based products. He’s passionate about web technologies and tries to stay on top of all JavaScript libraries and frameworks relating to Kendo UI, developing with jQuery, Angular, React, and Vue.js on a regular basis. In his free time Carl enjoys slaying virtual monsters, snowboarding and playing his guitar.

Related Posts


Comments are disabled in preview mode.