This is the first time I’ve seen Dave speak, and it was awesome. This talk wasn’t super code-heavy, but like some of the others, there are places where the notes aren’t so great because I can’t transpose a page of javascript into Twitter.
Oh, and the Divine Beasts is a reference to Legend of Zelda Breath of the Wild, which is like if traditional Zelda games and Elder Scrolls had a wonderful baby and I totally recommend it.
Now @davatron5000 is going to talk about “The Four Divine Beasts of Accessibility” – Zelda and accessibility! #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
. @davatron5000 started The Accessibility Project https://t.co/V3yOB7ekS2 – a community-driven effort to make web accessibility easier#AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
When you have accessibility issues on your site you’re confronting people with their disabilities. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
We should build accessibly because it’s our job.
“If you work on the web in any capacity, accessibility is your job.” @laurakalbag, Accessibility for Everyone #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
. @davatron5000 rolled his own accessible components for a client because their javascript and css was already so large he didn’t want to add another plugin to the site. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
Zelda Breath of the Wild is not too different from accessibility work.
Video games have a very intentional UX to teach you as you go.
Super Mario in the first 48 pixels teaches you everything you need to know to win the game #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
There’s a video series https://t.co/ZXrpzaVdtA that diagrams all the Zelda levels in a very simplistic way – but even then it displays how complex the system is#AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
Accessibility has evolving expectations. It helps to jump into a component (or a level) and figure out “what does this thing expect?” Expectations grow over time for everything we do. Best practices change – even for accessibility. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
“I didn’t get the memo, because this job doesn’t have memos… it just has angry blog posts” @davatron5000 speaks truth
— Anne Gibson (@perpendicularme) August 1, 2018
Sometimes it’s a puzzle to figure out what the expectations are. The WCAG guidelines are 1200 pages, and then you might find out the info you actually want is over on the WAI-Aria authoring practices page instead. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
How do we make some of this information about accessibility more consumable? Dave uses “Nutrition facts” as a model.
Tip: make your labels non-redundant. Nobody wants to hear “learn more” 8 times on a page. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
Dave’s component cards are at https://t.co/IYE3dvdHMd #AEADC #A11y
— Anne Gibson (@perpendicularme) August 1, 2018
Divine Beast #1:
Pop-up, popover, dropdown, hamburgers, fly-up, fly-over, fly-out, etc.On the nutrition cards, it’s referred to as a disclosure.
(Code time: not going to try to tweet the code. Come to @aneventapart if you’re not here!) #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
Adding aria-controls helps tell the system what the button controls. Adding aria-haspopup tells the screen reader to tell the user that the button opens a pop up. Adding aria-expanded tells the user whether the item is open or closed#AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
Then use javascript to change the state of the pop up, and also change the state of the aria tags so that they now reflect the state of the pop up. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
Divine beast #2: tooltips!
There’s both hover and focus states to be worried about. (This is the Tooltip on the nutrition cards.)Focus stays on the tooltip trigger while the tooltip is open. Good to know, Dave would’ve moved the focus to the tip itself w/o the specs. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
You can’t focus span elements. You have to add focus to the tooltip if it’s in a span – add it to a tabindex with tabindex=“0”
Make sure you bind the escape key to close a tooltip. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
Divine Beast #3 – Tabs!
The Tabs card on the nutrition cards is much bigger than the others we’ve looked at.
They have a lot of key bindings. Home goes to the first tab, and End goes to the last tab, for example. #AEADC— Anne Gibson (@perpendicularme) August 1, 2018
Focus expectations for tabs: tabs should activate automatically when rescinding focus as long as the tab panels are rendered quickly. (There may be some nuance battles around here.)
Aria-selected=“true” identifies the selected tab#AEADC— Anne Gibson (@perpendicularme) August 1, 2018
There are a lot of (good) aria controls we need to put on tabs to make sure that everything works, just in the HTML.
What’s expected in the JS:
Set ARIA on the tablist, ARIA on the tabpanel, and ARIA on the tab.
Handle keyboard events and clicks for tabs#AEADC— Anne Gibson (@perpendicularme) August 1, 2018
Divine Beast #4: Accordions! (Accordion on the nutrition cards.)
Keyboard expectations look a lot like the tabs.
Essentially they’re pop ups + tabs as far as expectations are concerned.
(TIL the accordion control should have role button!) #AEADC— Anne Gibson (@perpendicularme) August 1, 2018
In about 214 lines of javascript we have 4 accessible controls and that’s way better than loading all of Bootstrap #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
I’m not sure how clear it is in the tweets, but all the technology that Dave finishes his talk with is only partially supported. But hopefully this time next year we’ll be further along!
Coming soon to HTML and CSS:
<details>
<summary> Clickable and focusable summary</summary>
<p>Whatever you want to hide or collapse</p>
</details>Once this is in place we won’t need to roll our own accordion.
Not supported on Edge 17, *of course* sigh#AEADC— Anne Gibson (@perpendicularme) August 1, 2018
There are a few polyfills for the <details> tag. You might want to do some extra styling. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
<dialog>
What if you could make a modal in 4 lines of code? It’s been in Chrome for forever.
<button>Open Dialog</button>
<dialog> Hello I am dialog content </dialog>
Show Modal gives you backdrop.
Behind a flag in Firefox, no commitment for Edge or Safari.
Polyfills!#AEADC— Anne Gibson (@perpendicularme) August 1, 2018
“Rather than me implementing 700 modals poorly, wouldn’t it be nice if browsers had an accessible dialog?” that’s the way we need to push the web#AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
:Focus-visible
Don’t take the focus outline off a button.
Instead use
.button:focus-visible {
Background: dark blue;
}.button:focus:not(:focus-visible) {
Outline: none;
}this may not be the best solution but it beats what we (often) do today#AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
:focus-visible is really only in Firefox so we’ve got a ways to go until this is implemented everywhere.
“If there’s one takeaway I want us all to have it’s yell at browsers.” #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
@ inert (take the space out)
So when you hide something and I hide something it doesn’t look so good.
Inert tells the browser “this is rendered off the page, it’s not visible anymore, take it out of the accessibility tree.”
<div id=“hamburger-menu” inert> #AEADC— Anne Gibson (@perpendicularme) August 1, 2018
Tools and resources:
Accessibility for Everyone by @laurakalbag https://t.co/pWEmbJZn8vMIND patterns by eBay:https://t.co/cIcYPBDKDh
Inclusive components:https://t.co/88liIMGrPp
Accessibility for Teamshttps://t.co/3B3XXvJQ9N#AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
The A11y Projecthttps://t.co/dAigLQzEXj
Axe Developer Tools (chrome extension)https://t.co/B0AjVHBP9I#AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
(In the next 3 beliefs, Dave worded the sentences almost identically, and used the voice track to get the point across, so if you have the slides, yes, these look different.)
Belief 1
Designers and developers should code their own accessible components. You will learn a ton and have a better understanding of what’s expected and what to look out for and what to ignore #AEADC— Anne Gibson (@perpendicularme) August 1, 2018
Belief 2
Designers and developer should not [have to] code their own accessible components.These problems are old and we keep building them poorly. It would be better if they were build into the browser in the first place. #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
Belief 3
Designers and developers should [know how to] code their own accessible components.You need to know how to patch components, make them better, close gaps for the users#AEADC
— Anne Gibson (@perpendicularme) August 1, 2018
it is dangerous to go alone. Find resources online, talk to people on twitter, join the accessibility slack (https://t.co/wqiCeJVXa8 to join) #AEADC
— Anne Gibson (@perpendicularme) August 1, 2018