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.
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 :)
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.
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:
class=”menuItem”>Menu Item 1</
class=”menuItem”>Menu Item 2</
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 :)
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:
role=”menuitem”>Menu Item 1</
role=”menuitem”>Menu Item 2</
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:
Right after I typed “role” and hit the “=” key I immediately got a list of available roles.
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:
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
VS11’s intellisene even provides us with the appropriate options available to us
It even works with ARIA attributes that has multiple 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!
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.
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.
Carl Bergenhem is an Enterprise Solutions Consultant at Telerik specializing in the ASP.NET AJAX and ASP.NET MVC products. He has always been interested in web development and has played around with various web technologies since he was a kid. In his free time Carl enjoys soccer, running and playing his guitar.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.