ARIA (SydJS lightning talk)
•Transferir como ODP, PDF•
1 gostou•1,161 visualizações
Lightning talk given to SydJS, about using ARIA attributes as an off-shelf definition of state, as well as for accessbility. For a better transcript and some background, see http://weblog.200ok.com.au/2013/03/aria-sydjs-lightning-talk.html
Recomendados
Mais conteúdo relacionado
Destaque
Semelhante a ARIA (SydJS lightning talk)
Semelhante a ARIA (SydJS lightning talk) (20)
Último
Último (20)
ARIA (SydJS lightning talk)
- 1. ARIA SydJS lightning talk, 2013.03.20 Ben Buchanan / @200okpublic weblog.200ok.com.au
- 2. "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." - Tim Berners-Lee, 1997
- 4. This is relevant to your interests.
- 5. ARIA ● Accessible Rich Internet Applications ● Enhances the DOM ● Describes richer interactions
- 6. Reasons to use it ● Obviously, because a11y is good ● But also it's freakin useful
- 7. State reinvented over and over and over class="disabled" class="enabled" class="on" class="off" class="ticked" class="checked" class="focus" class="active" class="hidden"
- 9. "What meaningful properties does this object have at this time?" - http://www.w3.org/TR/2010/WD-wai-aria-primer-20100916/#properties
- 11. Link elements Bad: <a>Trigger</a> <div class="tooltip" id="foo"> Not announced</div>
- 12. Link elements Good: <a aria-describedby="foo">Trigger</a> <div role="tooltip" id="foo"> Announced</div>
- 13. Side by side Bad: <a>Trigger</a> <div class="tooltip" id="foo"> Not announced</div> Good: <a aria-describedby="foo">Trigger</a> <div role="tooltip" id="foo"> Announced</div>
- 14. Don't overdo it... ● Use core HTML where valid ● <input type="checkbox" disabled /> ● ARIA fills in the gaps ● <span role="checkbox" aria-checked="false" tabindex="0" id="chk1"></span>
- 15. Separate your functional CSS DOM: aria-hidden="true" CSS: [aria-hidden="true"] { display: none; }
- 16. Support
- 17. Careful! Browsers may rock at ARIA, but suck at assistive tech. eg. Firefox + NVDA = good Chrome + NVDA = bad
- 18. To summarise: Rejoice! ARIA means Javascript no longer kills kittens!
- 19. More info ● "Using WAI-ARIA in HTML" https://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index.html ● "WAI-ARIA 1.0 Authoring Practices" http://www.w3.org/WAI/PF/aria-practices/ ● ARIA on MDN https://developer.mozilla.org/en-US/docs/Accessibility/ARIA ● ARIA posts on TPG blog http://blog.paciellogroup.com/category/wai-aria/
Notas do Editor
- You've probably seen this quote before. It gets used a lot because it demonstrates the fact Tim Berners-Lee's vision for the web has always been one of inclusivity. Quote source: http://www.w3.org/Press/IPO-announce or http://www.w3.org/standards/webdesign/accessibility if you prefer.
- During a recent speaking tour, he said accessibility has come a very long way (when considered over a decade-long period – big picture). But he also warned that JS-heavy applications were a great risk to that progress. Image source: http://www.pocket-lint.com/news/46694/sir-tim-berners-lee-olympic-tweet TimBL paraphrased from a Q&A session at UNSW, 2013.02.01
- As the people writing those JS-heavy applications, this is relevant to your interests... For a long time, accessibility was touted as a bluntly JS-on or JS-off dichotomy. That misled many people into thinking accessibility was too hard; or that if you wanted to do cool stuff you were excused from accessibility. That of course is bullshit. You can do all the JS ninja stuff you want and still make it accessible.
- The basics are still pretty easy: test the keyboard, check the colours, ensure there's alt text. It's the richer DOM work that is harder: updating the DOM, linking elements, elements behaving like other elements. The problem with screen readers they were built to meet a load once, render once paradigm; but DOM changes weren't picked up. ARIA describes the state of the DOM in ways assistive tech can read, basically bolting accessibility back on where it had fallen off.
- The cool thing though is you should also think about using ARIA purely because it's frickin useful.
- People reinvent state, over and over and over. Disabled, enabled, on, off, active, hidden...
- No matter how you're bunging this stuff into the DOM, you're still having to define and implement it all; and document it for the next person.
- What's interesting is all this information is the same information assistive technology needs. In order to describe rich interaction, ARIA had to define it .
- This gives us a standardised list of common interaction states, element attributes and roles... AND it makes that accessible to assistive technology.
- A quick example here is a tooltip. The second element is often generated from title text, but the title has to be supprssed to avoid double up. So once you turn it into a tooltip it's no longer available to assistive tech. There is no link between these two elements in the DOM, the DIV is commonly appened to BODY and floated.
- Simply by changing the class to a role; and using described-by, you can solve these problems. The elements are linked in the DOM and assistive tech knows that random DIV is actually tooltip (which is a defined widget type). I can vouch this works as I've tested it, while creating a pull request that's been ignored for going on six months now... CAVEAT: presumes there is a role="application" or "document" higher up the DOM.
- And just a quick side by side to make it easier to see how similar the code is. While ARIA can be a little verbose, it's quite readable.
- The ARIA spec itself is very clear on this: use ARIA when there is a gap that needs to be fixed. That includes gaps you've put in yourself ;) Checkbox code from https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_checkbox_role
- What's interesting is once you start using ARIA states like this, you can separate the CSS that's not concerned with how things look. Many widgets have a small amount of functionality-related CSS; so you can attach that to the same attributes you're using for behaviour.
- Screenshot from http://caniuse.com/#feat=wai-aria
- Just be aware that not all combinations are equal. This is not cause to panic, just test with the right stuff. Webaim have a great guide for this: http://webaim.org/articles/screenreader_testing/
- You already define state and manipulate the DOM. Use ARIA to do it and make your stuff accessible!
- One little home truth about ARIA is the specs are really hard to read. Seek out these dev-friendly options instead of the raw specs!