Real JavaScript Ninjas should know how to role with WAI-ARIA
•Descargar como PPTX, PDF•
4 recomendaciones•3,012 vistas
ARIA provides a lot of really useful additional semantics to HTML 5 that , if used properly, can lead to awesome accessible UIs
Recomendados
Recomendados
Más contenido relacionado
Similar a Real JavaScript Ninjas should know how to role with WAI-ARIA
Similar a Real JavaScript Ninjas should know how to role with WAI-ARIA (20)
Último
Último (20)
Real JavaScript Ninjas should know how to role with WAI-ARIA
- 1. Real JavaScript Ninja’s know how to role with WAI- ARIA
- 2. Dylan Barrell Twitter: @dylanbarrell, @unobfuscator GitHub: dylanb http://unobfuscated.blogspot.com/
- 4. 8 trillion
- 5. $8 trillion
- 6. 15%
- 7. 1 billion
- 8. P O U R
- 10. Role Name State(s) Value Call a Spade a Spade
- 11. Keyboard (and gestures) – add graphic of a Braille keyboard
- 18. Insert periodic table of ARIA roles
- 19. • ARIA roles: – Provide the ability to control the transition between application (forms) mode and document mode – 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 around it
- 20. Insert periodic table of ARIA attributes
- 21. • 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 attributes – Add some attributes for better control of what is spoken by the screen reader versus what is simply there for presentational purposes
- 24. First rule of ARIA – If there is a native HTML element that does the job, use that Examples 1. Use <button> and <input type=“submit”> NOT <a role=“button”> 2. Use <ul>, <ol> and <li> NOT <span role=“list”> etc.
- 25. Compelling ARIA roles • Landmark Roles – main, search, navigation, contentinfo, complementary, banner – region in combination with aria-label • Live Region Roles – log, status, alert • Some Widget Roles – – – – tabpanel and tab slider 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
- 26. 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
- 27. ARIA holes • Tables, tables, tables – Use the a11yfy library • Arrow keys on iOS – Insert dynamic modal content in line – Use gestures • Gestures – Think hard about your mapping to the portable gestures – add on screen controls where possible
- 28. Accessible Gesture Calendar Example https://github.com/dylanb/gestura11y http://dylanb.github.io/datepicker/datepicker.html • Shows use of tabindex to control focus • Shows use of role=“application” to force application mode • 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 gestures • Shows how to ensure that gestures are consistent regardless of zoom level
- 29. Accessible Gesture Calendar Example https://github.com/dylanb/gestura11y
- 34. Third rule of ARIA – Always attach your event handlers to the same element that has the role and the focus If you stick to this rule, you will avoid events not being delivered consistently
- 35. Fourth rule of ARIA – In complex widgets like menubars, tabpanels etc. always make all interim structures presentational
- 36. Fifth rule of ARIA – in a complex widget where you are managing focus, disable all naturally focusable elements with tabindex=“-1” Example is the a11yfy menu examples where the anchors are given tabindex=“-1”
- 37. Finally There is a wealth or resources including The ARIA specificationhttp://www.w3.org/TR/waiaria/ The Authoring Practices http://www.w3.org/TR/wai-aria-practices/ The WAI Web Site http://www.w3.org/WAI/intro/aria Mozilla Developer Network https://developer.mozilla.org/enUS/docs/Web/Accessibility/ARIA
Notas del editor
- Vice President of Product Development at DequeMaintain the a11yfy jQuery open source libraryMaintain the open source node-mimejs mocking-capturing libraryjQuery UI accessibility contributorInteresting facts: Love JavaScript, Love Dancing have a Son studying computer science at Michigan
- 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.
- Here is the current list of all the HTML 5 elements grouped into Josh Duck’s groupings of Text-level, Metadata and Scripting, Embedding content, Grouping Content, Forms, Document sections, Tabular data and Interactive elements. Now the forms and tables obviously form a big part of what we see on the web, but the thing that strikes me when I look at this picture is of all 100-something elements, only 4 of them are grouped into the category of “Interactive Elements”. The Web would be a pretty boring place, if that was all that was possible.Also, I have actually never ever seen one of those elements actually used in the wild. Has anyone here ever used or seen one of the elements - menu, command, summary or details used on a web site or application?This gives you an idea of some of the problems that accessibility faces without ARIA. It is not possible to easily communicate to the user the roles of the elements that they are interacting-with.HTML (including HTML 5) was really designed with content (and not applications) in mind but has been enhanced by JavaScript and CSS to implement web applications. The problem with that is that accessibility for dynamic web applications has been made difficult and in some cases impossible to achieve when only using HTML. Let me show you 4 of the most common types of problems that dynamc web applications face with respect to accessibility.
- 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.
- What does this image look like? It looks like a calendar date picker widget. Actually, it is implemented as a table. As a keyboard-only user, like a screen reader user, to navigate and find a date effectively, I would expect to be able to use keys like the UP arrow, DOWN arrow, Page Up, Page Down etc. The problem is, that he screen reader interprets these keys to allow the screen reader user to quickly navigate the page. So arrow down will navigate to the next element in the DOM instead of being delivered to your JavaScript handler.If the user is persistent and knows he/she is in a datepicker, then they could try to switch to application mode using the shortcut key for that, but when they do that, the screen reader may turn off the table announcements, so whereas they gain the ability to send keyboard commands to the JavaScript handlers, they would lose the information about where they are in the table.In pure HTML 5, you are forced to implement this as a standard table with links on each day and allow the user to tab back and forth through the days. The keyboard-only users loses the ability to efficiently navigate to the next month, week etc. with the page or arrow keys. A pretty bad experience for all keyboard users.
- 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.
- There are two practical and one architectural hole in ARIA.The biggest practical problem with accessibility in general today is table support. iOS and OS X have different and bad support for 3D tables. In addition, there are problems with tables from a responsive design perspective. My suggestion is to use the a11yfy library when you want/need tables as it has quite comprehensive support for all the things that are possible including responsive tables.The second practical problem is that currently when VoiceOver is turned on and a keyboard attached to an iOS device, it is not possible to get access to the arrow key events inside a JavaScript event handler. Add to this the difficulties that iOS has with table markup and you have a real recipe for difficulty.The architectural weakness is that ARIA is silent about gestures. In addition, screen readers treat them totally differently. On mobile devices, they all get intercepted and the gestures you use are totally different from when the screen reader is turned off. Some screen readers have ways to allow gestures through and some do not. Then there are undocumented behaviors when ARIA roles are applied to the focused elements.From a practical perspective, the application role is useful in getting gestures to work on iOS, but Android does not have support for gesture pass-through and you can only reliably get access to about 10 gestures on iOS when VO is turned on. A specification called IndieUI is being worked-on that will address some of these issues but for now, you have to use gestures to replace arrow keys on iOS but there is no good solution for Android
- 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.
- Now lets turn to the code:If you go to hammer.js/index.js on line 1165, you will see a modification I made to allow gestures to be supported regardless of zoom level.The way that JavaScript gestures work, the velocity is calculated as the number of pixels that are swiped in a given time. However if the user has zoomed in (which will happen automatically if the user puts focus into a form field), then the number of pixels swiped for a given screen distance will be lower. Under thee circumstances – particularly if the user is blind and has not noticed the zoom, it becomes difficult to reliably generate the gestures.By calculating the zoom level with:zoomLevel = ev.target.ownerDocument.defaultView.innerWidth / ev.target.ownerDocument.documentElement.clientWidth;And then multiplying (which will actually reduce it) the threshold for a swipe gesture by this fraction, we get much more predictable gestures.Note that the standard Hammer.js library does not have this code.
- 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.