Deque is a pioneer in the accessibility industry. Since 1999. Our mission is digital equality. We are a software-based services company. Three main products are the FireEyes accessibility plug-in for Firebug, WorldSpace Enterprise accessibility analysis and reporting tool and the 2013 Computer World 21st Century Award Innovation category winning Amaze – a product for making web applications accessible without source code changes.
What does the number 8 Trillion have to do with accessibility?
$8 Trillion dollars is the yearly spending power of people with disabilities and their immediate families according to Gartner
15% of the population in the World have a disability
That is approximately 1 billion people
Why is accessibility like a Guinness? Because Guinness is all about the POUR and accessibility is all about POUR too.
P.O.U.R. stands for Perceivable, Operable, Understandable and Robust the four principles of accessibility that underpin the WCAG 2 standard.WCAG 2 Guideline 1 deals with issues of perceptionGuideline 2, with making UI components operable with all sorts of input devicesGuideline 3, with making the page, the UI and the content understandable, andGuideline 4, with making it work across all devices and user agents
What does a spade have to do with accessibility? Ever hear of the saying, call a spade, a spade. Well one of the principles of accessibility is: Role, Name, State(s) and Value.
The third important principle of accessibility is to make everything keyboard accessible and to ensure that that keyboard accessibility works with assistive technology like a screen reader turned on. Focus management is a big part of this and tabindex is your friend when it comes to focus management.
You probably all recognize this GitHub repository creation form. It’s a pretty simple form – right?How many labels/instructional texts does the “repository name” input field have? In my opinion, there are at least 3 associated pieces of information for that field, the account, the text “Repository Name” and the additional information about what makes a great repository name. You could argue that there are 2 other pieces of information associated with that field: the fact that you are creating a public repo and the slash between the account and the name.At any rate, even with just three labels, it is not possible to elegantly solve this problem purely with HTML 5 for a screen reader. You end up being forced to replicate the instructional or labeling information into off-screen text and you do not have fine-grained control as to when the information is read. You could definitely make a case for the additional instructions “Great repository names are short and memorable, Need inspiration? How about ‘tripping avenger’.” To be read only after all other information about the form and also to be interrupted if the user starts to type.
Who recognizes this? This is the “waiting” gif. It and its brethren were introduced because of AJAX. To inform users that the browser was doing something and they should wait. Generally when this disappears, the page is dynamically updated in some way. Sometimes, this guy is not used and the page simply updates itself automatically. Think about Facebook chat or Twitter. With HTML 5 it is not possible to maintain focus on one part of the screen, but tell the screen reader user about an update that occurred on another part of the screen. This makes that sort of dynamic UI very difficult – sometimes impossible – to make accessible.
Take a look at this screen shot of my GitHub profile page. You will notice it has quite a lot of information on it. One of the things it has is a tabbed user interface. This user interface is implemented using? Anyone? Of course, an unordered list. Now going back to our Role, Name, Value State discussion, what is the state of the first tab in the list of three tabs? It is the “Selected” tab. In HTML 5, there is no standard way to communicate that to the screen reader other than adding off-screen text. This is ok, but it needs to be maintained, translated etc. and it results in a different experience for the user every time they encounter tabs on the Web.You will notice that the developer who created this page, put a “selected” class on the anchor inside the list item, which CSS uses to style that tab differently. But the screen reader does not know anything about the semantic of that class as the class name itself could be called anything.
HTML 5 logo and a thumbs down image. Now I love HTML 5. But from an accessibility perspective, it still really sucks. Luckily ARIA, which stands for Accessible Rich Internet Applications has come to the rescue.
When you create a table of elements with the ARIA roles, you can immediately see where HTML 5 has been significantly enhanced by the WAI-ARIA roles. You will notice a significant increase in the number of interactive roles, a significantly larger number of roles allocated to document structure and some new roles related to forms.
Looking at the ARIA attributes, you see that additional semantics added by the roles, further enhanced and supported through some additional standardized state and value attributes that support interactivity. But also some attributes to help with naming, in particular, the ability to have different types of labels (a describedby and a labelledby)
Example of role-specifying attributes are aria-readonly and aria-required – when added to a form field, they further clarify what role those form fields play within the form
So ARIA is perfection right (image of a Ferrari)?
Actually, it is far from perfect, but it is practical. Image of a shiny new minivan
I am now going to tell you about the ARIA attributes that work well, but remember, wherever you can, use the standard HTML elements where those exist already. Here are some examples, but these are but a few. The reason for this is that these built-in components all support all the assistive technologies well. If you simulate them with ARIA, you MUST supply all the behavior yourself and you will not be able to be used with older technology. ARIA is best used when doing things that were not possible with older assistive technology.
Some of the roles and attributes do work very reliably and give you functionality that is indispensible for achieving compelling accessible applicationsThe landmark roles are very well supported and every page should use themThe live region roles are a little problematic in that they do not simply work as specified everywhere, but by following some simple rules you can get them to work on all platforms. Us ethe a11yfy library if you don’t want to worry about the details yourselfMost of the widget roles work across all browsers. In particular, I find the ones listed on the screen very usefulThe form roles all tend to work well but I would defer to the native HTML elements – the exception is if you need to style radio buttons and check boxes, then these roles come in useful and will allow you to support iOS where some of the hacks with off-screen native elements and presentational <div>s fall downThe role=“presentation” is a special role. It can be used to tell the AT to ignore the native semantics of the HTML structure and treat everything as if it was a div or a span. nOt that I would suggest you do this, but if you have layout tables, then adding role=“presentation” to that layout table will make the screen reader treat it like a bunch of divs instead of a table.
Unfortunately, even some very widely spread examples do not work on all platforms, the landscape is changing, so new releases of iOS could fix (or break) things. Apple does not publish its bug fixes or new features, so you just have to test.
You can clone the repository and follow along as I walk through the code. https://github.com/dylanb/gestura11yYou can also try out the example at http://dylanb.github.io/datepicker/datepicker.html
Now lets look at the UI. There is a basic calendar month layout with days of the week at the top and the date numbers aligned underneath those. The table is headed by the month and the year. There is a button at the top to go to the previous month and a button to go to the following month. By default, it opens up on the current month.There is a highlight on the currently focused day for keyboard only sighted users. There is also a focus indicator when the widget itself has focus.A keyboard user can use the arrow keys to move left right and up and down. If the user moves off the top or the bottom of the month, then the widget will advance or retreat by a month.Clicking the Previous and Following buttons will also retreat or advance by a month. The keyboard user can use Page up and Page down to also achieve this retreat and advance functionality. Home and End will move to the last and first day of the month respectively.The gestures of drag left, right, up and down do the same as the arrow keys. Swipe left goes to the beginning of the month. Swipe right goes to the end of the month. Swipe up goes to the previous month and swipe down goes to the next month.Tapping, clicking or pressing enter will select the date and the date picker will disappear, replaced by the selected date.When a screen reader is turned on, advancing the current day to any other date, will read out the entire date – for example January 10 2014
Looking at the HTML markup that is generated by the code, you will see firstly an offscreen <div> that has the role of “log” and the attributes aria-live=“assertive” and aria-relevant=“additions”. If you look at this once you have been using the widget, you will also notice a bunch of <p> tags with dates inside them, only one of which is not display:none – the last one. This is aria-live being used to announce updates because the user’s focus is on the table as a whole, this is the technique that is being used to announce the currently “selected” date to the user with a visual disability.
The second thing you will see is that the table has a tabindex=“0” attribute. This is to allow it to receive focus. It needs to receive focus because we need a way to tell the screen reader when to switch into application mode and ensuring that the table receives focus and then adding an application role to the table will do this. We can then attach or delegate event handlers on the table to deal with keyboard and gesture events.You will also notice that the <thead> and <tbody> elements have aria-hidden=“true”. This is so that a screen reader user does not have to traverse past the entire table structure. The entire table looks like a single widget to the screen reader user. The same as it does to a sighted user. The screen reader user only perceives what is announced to him/her via aria-live.The aria-live technique is a very common technique – especially to get around some of the difficulties that you would otherwise have getting the table markup to work well on all platforms. It can also be used to implement other dynamic content like tooltips, chat widgets, busy icons, progress etc. etc.The aria-hidden technique is useful to hide content from a screen reader when it is redundant or presentational. Another example would be walking directions where there are both turn-by-turn instructions and a map. A blind user may want the turn-by-turn but will not be interested in the map itself.
The most interesting thing about this code is that – other than the code to draw the table and calculate where the days go and which day is currently selected and which day to move to next on a gesture or a keyboard event, most of the code is just event handler code.The only really interesting thing about this is that all the event handlers, except the one to click and select a day, are attached to (or delegated from) the same element that has the role – the table element itself. This is one of the rules
Which brings us to the 3rd rule of ARIA – always align focus, roles and event handlers.
If you do not do this, you will see strange behavior like for example the counts of items being wrong
This way you can guarantee that using a combination of tab key and arrow keys will work correctly
But remember the second rule of ARIA – test yourself for support.
how to role
• ARIA roles:
– Provide the ability to control the transition
between application (forms) mode and
– Provide more native announcments for
widgets like menus, tabs, sliders etc.
– Provide for the ability to control
announcements when updates occur away
from the focus
– Provide much more control over the structure
of the document and how someone navigates
• ARIA attributes:
– Solve the problem of multiple labels and
descriptions through the addition of finergrained labeling attributes
– Enhance the ARIA roles through the addition
of standard state, value and role-specifying
– Add some attributes for better control of what
is spoken by the screen reader versus what is
simply there for presentational purposes
First rule of ARIA – If there is a native
HTML element that does the job, use
1. Use <button> and <input
type=“submit”> NOT <a
2. Use <ul>, <ol> and <li> NOT <span
Compelling ARIA roles
• Landmark Roles
– main, search, navigation, contentinfo, complementary,
– region in combination with aria-label
• Live Region Roles
– log, status, alert
• Some Widget Roles
tabpanel and tab
menu, menubar, menuitem and associated attributes
dialog – in combination with the document role to get it to
work in NVDA
– tree and treeitem – a bit tricky to get to work reliably
• Some form roles
– button, textbox, checkbox, radio, radiogroup
• presentation role
Second rule of ARIA – test it on all
YOUR platforms with the assistive
technology YOU support
All platforms have problems, most
have workarounds, iOS is the
most problematic and Android is
not quite ready for prime time yet
• Tables, tables, tables
– Use the a11yfy library
• Arrow keys on iOS
– Insert dynamic modal content in line
– Use gestures
– Think hard about your mapping to the
– add on screen controls where possible
Accessible Gesture Calendar Example
• Shows use of tabindex to control focus
• Shows use of role=“application” to force
• Shows use of aria-live regions to announce the
current date as the user moves around
• Shows use of aria-hidden to hide presentation
markup from the screen reader
• Shows use of keyboard handler and mapping to
• Shows how to ensure that gestures are consistent
regardless of zoom level
Accessible Gesture Calendar Example
Third rule of ARIA – Always attach
your event handlers to the same
element that has the role and the
If you stick to this rule, you will avoid
events not being delivered
Fourth rule of ARIA – In complex
widgets like menubars, tabpanels
etc. always make all interim
Fifth rule of ARIA – in a complex
widget where you are managing
focus, disable all naturally
focusable elements with
Example is the a11yfy menu
examples where the anchors are
There is a wealth or resources including
The Authoring Practices
The WAI Web Site
Mozilla Developer Network