1 2 So who died and appointed me boss? What do I even know? I dont - - PDF document

1 2 so who died and appointed me boss what do i even know
SMART_READER_LITE
LIVE PREVIEW

1 2 So who died and appointed me boss? What do I even know? I dont - - PDF document

1 2 So who died and appointed me boss? What do I even know? I dont have a certification. I dont habitually use assistive technology to access the web. My job description doesnt include anything about accessibility, but Im the one


slide-1
SLIDE 1

1

slide-2
SLIDE 2

2

slide-3
SLIDE 3

So who died and appointed me boss? What do I even know? I don’t have a certification. I don’t habitually use assistive technology to access the web. My job description doesn’t include anything about accessibility, but I’m the one who has ended up leading this effort at our organization. I’m a front end web developer. I’m a team

  • lead. I’m not the Accessibility Compliance Director, we don’t have an Accessibility Office.

This whole exercise is about empowering you – all of you – to be accessibility advocates. You don’t need to be part of a particular demographic group. You don’t need to have a particular job title. I was a plain old front-end developer who thought this was important when I started this journey. You don’t need to know all of the things. The resources are out there if you’re looking. You do have to be willing to speak up. 3

slide-4
SLIDE 4

4

slide-5
SLIDE 5

They will find you. They will sue you. And they will win. Imagine if you will, a person who runs a store. The sidewalk out front is broken, but instead

  • f fixing it they’ve put away money in a “lawyers and settlement” fund for when they get

sued for a slip-and-fall. Weird business plan. 5

slide-6
SLIDE 6

Don’t disappoint Ben Franklin. Deciding out of the gate that we don’t want to bother to accommodate a whole swath of customers seems like an odd business decision. According to Pew Research, nearly 40 million Americans had a disability in 2015, 12.6% of the civilian non-institutionalized

  • population. (http://www.pewresearch.org/fact-tank/2017/07/27/7-facts-about-americans-

with-disabilities/) Remember, people who use assistive technology have wallets just like everybody else. How many customers are you willing to lose because user focus gets trapped in the “billing address” tab of Checkout? Or because they can’t select a date with the keyboard? 6

slide-7
SLIDE 7

40 million Americans is about the population of California and Montana combined. Would you launch a product and market it nation-wide except for California and Montana? 7

slide-8
SLIDE 8

Customers are adding accessibility requirements in their contracts. True fact, we have a customer who came to us with accessibility requirements. “We will be your customer and spend x frillion dollars. But if our audit shows that your web experience does not meet our accessibility requirements and you can’t fix it in five days, we get to take our dump truck full of money and go home.” 8

slide-9
SLIDE 9

Be guided by thinking about how you move through the world – think about that kid song, “Head, Shoulders, Knees, and Toes.”

  • Hands – drive the song, despite not getting any credit. Hands are the drivers of our
  • nline mobility, just like feet are in the offline world. Mobility issues can be temporary,

like being in a cast, or permanent, like dealing with a persistent issue like Parkinsons

  • tremors. Mobility issues can be minor, like the mouse being on the wrong side at my

left-handed mother’s house, or major, requiring the use of a joystick powered by mouth

  • r eye-tracking glasses. The good news: the good practices we use to provide the best

user-focused web experience are exactly the solutions for people with mobility issues.

  • Head: Think about processing issues. What to do? Make sure your text is easily legible,

and chunked into sections set off with good headings – which you should already be

  • doing. It’s user experience best practices.
  • Eyes: Vision issues cover a lot of ground. Colorblindness, limited visual field, blindness.

Check your contrast, use color to reinforce your messaging, not as the primary carrier. Be mindful that people with limited vision may zoom in dramatically to only view a small portion of the screen. Keep your error messaging close to the offending field or they’ll miss it. Those who access the web through screen readers need your source code presented in logical order.

  • Ears: Much of the web is visual…until we get to video. Supplying those captions will be

important for anyone who has their volume turned off, or for those with auditory issues. 9

slide-10
SLIDE 10
  • Nose: So far, we don’t have to worry about accommodating anosmia (there’s your new

word for the day – “the loss of the sense of smell.”) until they develop reliable and ubiquitous smell-o-vision. 9

slide-11
SLIDE 11

Just like in the physical world, accommodations for people who need them help people who don’t need them too. Lever-style door handles are critical for people with arthritic hands. And super useful for those times when you’re trying to get all the groceries into the house in one trip. The automatic doors are critical for people with mobility challenges. And they’re really handy for people pushing a stroller. Ramps are essential for people who need wheelchairs. And for the UPS driver with a dolly full of packages. In the same way, online accommodations online that make our code more mindful, our architecture more apparent for assistive technology also end up providing a better experience for all of our users. Including search engine robots. 10

slide-12
SLIDE 12

It’s financially smart. It’s morally right. It benefits everyone. 11

slide-13
SLIDE 13

Look, now you know why we should bother building in accessibility! You deserve a high five from a kitty cat! 12

slide-14
SLIDE 14

https://www.w3.org/TR/WCAG20/ Web Content Accessibility Guidelines (WCAG) 2.0 13

slide-15
SLIDE 15

The standards for accessibility compliance are described by the W3C – the same people who decide what web standards are. The legal requirements are found in Section 508 of the Rehabilitation Act of 1973 (the “what”) and the Americans with Disabilities Act of 1990 (the “why” – this civil rights law prohibits discrimination based on disability). Committing to compliance means different things for different roles. For Content Editors, the focus will be on alt tags and easily understandable copy, plus captions and transcripts for video content. It means making sure that the pages we build aren’t structured in a way that a screen reader would make confusing. For Developers, the first step is good understructure – valid and complete markup. Form inputs need labels. Tables need headings. Relationships between elements get captured in code with aria tags. The next step is to provide control to the user. No autoplay. For QA, it’s learning to use assistive technology like screen readers to make sure all of this is working together. https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0 https://www.section508.gov/manage/laws-and-policies 14

slide-16
SLIDE 16

These resources are authoritative, comprehensive places to get a handle on accessibility issues. 15

slide-17
SLIDE 17
  • Be predictable: Using semantic markup and consistent design elements provide assistive

technology with the hooks to programmatically determine content relationships – which heading goes with which text, for example.

  • Give the user control: Don’t let things autoplay. (Remember, ads autoplay – and we have

gotten very good at ignoring ads.) Let me pause, go back, change the volume. Give me error messages that point me in the right direction and tell me how to fix the problem.

  • Provide alternatives: Give me another way to access the content - is your button

keyboard accessible? Does your video have captions? If the page I want is in a dropdown menu, is there another way to get there? 16

slide-18
SLIDE 18

You’re probably already doing things that keep your code accessible. Just because you’re a good developer. And because Drupal’s got your back. Some things are low-hanging fruit. Why would you want to create a web experience that’s consciously irritating, like flashing content? Keeping your IDs unique will make your QA tester happy. Error-free javascript should always be our goal. Who wants IE11 to throw up its metaphorical hands in surrender because it encountered a javascript error? 17

slide-19
SLIDE 19

Content management systems like Drupal make it easy to provide consistent menus and helpful error messaging. And the language of the page is already coded into the page template – all you have to do is not break it. 18

slide-20
SLIDE 20

You might have never even seen the skip-to-main-content link. It only makes an appearance for screen readers and keyboard navigators. To your design eye, it might seem jarring and unexpected, but it’s an essential time saver to folks who need it. 19

slide-21
SLIDE 21

https://webaim.org/resources/contrastchecker/ Start with the official organization color palette, but validate that it works on your

  • background. Just because it’s a brand color doesn’t mean that brand color works in that

context. What if it doesn’t? Go back to the requestor – “Using this color text doesn’t pass accessibility guidelines. Can we use (provide alternate official color) instead?” This is a great way to take the personality out of pushing back. It’s not “your design is bad and you should feel bad”, it’s just math. And that makes it a lot easier to end up with a more accessible design. 20

slide-22
SLIDE 22

Use <p> for paragraphs, <li> for list items. Break up your page with HTML 5 sectioning elements, like <header> <footer> and <main>. A screen reader relies on those semantic elements to get the gist of the page’s message. And it can leverage those elements to provide productivity enhancements, like grabbing all the headings on the page, allowing the user to jump straight to the section they need – like “What to Bring.” Use your code to reinforce your message, and don’t rely on class names to visually supply a heading-like treatment for things that aren’t headings. If it’s not a heading, why are you styling it like it is one? If it’s doing a heading’s job, give it the heading’s markup. 21

slide-23
SLIDE 23

<title> is what gets captured in your bookmark – and grabbed in your history. Ever try to navigate back to a particular page on a site and all the pages have the same title? Which

  • ne has the content you need?

Tables can be particularly difficult to navigate for someone using assistive technology. Imagine having someone read an Excel table to you. What column are we in? Which heading owns this data? Keep tables confined to tabular data, not just because something needs to be lined up. (HTML emails - that’s a whole different story.) The most common error you’ll see after running an automated accessibility audit is form inputs without labels. Every input needs a label, even if it looks so much sleeker without

  • them. Placeholder text is NOT a replacement for a label. It disappears as soon as you really

need it – was that date supposed to have a four-digit year or a two-digit one? I never

  • remember. Form error messaging requirements illustrates the difference between the

levels of compliance. 22

slide-24
SLIDE 24

From any page, it should be easy to find a way to the Site Map or the Search functionality. (If it’s not, studies show users will bounce and head back to Google to find the information they need. And maybe they won’t end up on your site. Don’t take that chance.) 23

slide-25
SLIDE 25

Words should be words, not pixels. If your message is important, make sure everyone can read it. If it’s not important, why is it cluttering up your painstakingly selected image? 24

slide-26
SLIDE 26

It can be particularly difficult to choose text placement, font size and font color for legibility in every circumstance. “Make” pops on the sliced ginger, but “powder” is nearly illegible in the shadow. If you’re providing content editors with ways to add text on top of images, eventually you’ll get a result like this one. And why even have this text? It’s reinforced in the URL and in the H1 on the page. 25

slide-27
SLIDE 27

Sometimes, you’ll need to implement a semantic image as a background – because CSS. Let’s hear it for background-size: cover; In that case: Give your container the role=“img” Add an aria-label=“” to contain the text that would be the alt tag if this were an <img>. Text on top of a background image can be difficult to read. Watch your contrast! http://www.brandwood.com/a11y/ 26

slide-28
SLIDE 28

How to write good alt tags: Tailor your alt text to the image. True story: I worked with a site that had about 100 logos

  • f the business’ partners – every single alt tag was supplied as the business unit’s name.

Not the name of the logo owner. So that was fun. Make your alt tags meaningful: How can you describe what’s going on in the image so that someone not looking at it would understand the same meaning? “tree” is an accurate alt tag for this image – but it misses the mark. Avoid “image of” – the screen reader will already have read out that it’s an image. “image. Image of tree with googly eyes.” 27

slide-29
SLIDE 29

Sometimes you don’t need the alt tag. If the text that you’d put in an alt tag is in a caption together with the image, an additional alt tag that just repeats what’s in the caption isn’t necessary. If your image is strictly decorative – an alternative to a plain color background, for example – you don’t need to describe that it’s dark blue. You’re not providing any additional information. Some content management systems (looking at you, Drupal 8) require that all images uploaded as images have a non-empty alt-tag. When you’re required to provide an alt tag that wouldn’t be terribly useful, go minimalist. 28

slide-30
SLIDE 30

Screen readers can present links in a list – imagine being presented with a list like this.

  • Purchase course materials
  • Learn more
  • Apply for Waiver
  • Learn more
  • Register
  • Learn more
  • Learn more
  • Learn more
  • Learn more
  • Learn more

Make sure your clickable text has clues about what the user can expect to happen next, even if it’s taken entirely out of its context. 29

slide-31
SLIDE 31
  • Best-in-class user experience puts the user in the driver’s seat. That same philosophy

drives accessibility accommodations. 30

slide-32
SLIDE 32
  • If your page includes foreign language phrases, tag them with their language. (No need

to tag small things that follow the main page’s pronunciation rules. A screen reader will breeze right through “taco.” But longer passages may need a different pronunciation

  • engine. I’m pretty sure Swedish for “turn left” isn’t “slung til monster” but that’s sure

what the GPS made it sound like…)

  • If you’re providing live video, make sure your budget includes captioning.

31

slide-33
SLIDE 33

Watch TV with the closed captioning on – sometimes you’ll see additional information conveyed by sound, like “sad song plays” or “dog barks in the distance.” That’s descriptions. 32

slide-34
SLIDE 34

Don’t let these attributes fight the battle for accessibility alone – combine them into a crime-fighting team! 33

slide-35
SLIDE 35
  • Datepickers. They’re basically the worst. This code includes aria tagging that gives the user

a chance at understanding where they are. Many datepickers don’t. Drag and drop interfaces are also an unsolved problem for accessible interfaces – this is an

  • pportunity to provide an alternative method.

34

slide-36
SLIDE 36

Make this a part of every new page implementation.

  • Take special care with popups – be able to close the popup without the mouse, and then

land in a place you expect. 35

slide-37
SLIDE 37

NVDA: https://www.nvaccess.org/download/ 36

slide-38
SLIDE 38

Good news! Many of the things you do to be a good developer are just the sort of things you need to do to produce accessible web pages. But be aware, there are some things you’ll need to manually test. An automated test can walk through your markup, but it can’t tell if it makes sense in the order of its walk. 37

slide-39
SLIDE 39

38

slide-40
SLIDE 40

Hopefully “accessibility” doesn’t seem like such an undiscovered country anymore. You now have some insight into what ways users are accessing (or trying to access) our sites. So when you’re tasked with posting something with video assets, make sure you ask the content owners if they’ve considered captioning and transcripts. For a new page design, be aware of contrast rules. Write good code. 39

slide-41
SLIDE 41

We’ve developed a checklist to help guide your efforts to keep your pages accessible. It’s shared on a Google doc at the above shortlink. It attempts to put all the AA-compliance hitches our organization typically encounters into an order that walks through the page

  • nce.

40

slide-42
SLIDE 42

Automated accessibility testing can get you a long way. The aXe extension for Chrome is an excellent tool – but only if you use it. After the extension is installed, all you have to do is open up developer tools and click on the aXe tab. Click “Analyze” and aXe will perform an accessibility check. 41

slide-43
SLIDE 43

Once you’ve got the results back, aXe will flag the issues it found. Resolve violations – or if it’s a heavier lift than the ticket can take, bring that issue to light. In retro, bring it up and see if it can be addressed (or if it’s already being addressed by another team). aXe will provide instructions for how to fix the violation. “Needs review” issues can often be ignored. Many of them will be “Contrast text vs. background can’t be determined.” Do a contrast check and see if it passes. Some things won’t be under your control – like code that gets embedded from other libraries, like HubSpot forms or social sharing links. 42

slide-44
SLIDE 44

You’ll see that this audit includes “Additional items to manually check.” The automated tools are great, but they can only get you so far. Programmatically, you can determine which colors are used on what backgrounds, the audit can tell if a rule has been broken – like an input missing a label. Which is probably your most common one. It can’t tell if the tab order is logical. It can identify what the tab order is but so far whether or not it’s confusing remains a human decision. All the automated check is aware of is the DOM

  • rder; if that doesn’t match visual order, you’ll end up with confusing results.

43

slide-45
SLIDE 45

Lose focus and you’ll end up with a market umbrella blocking your ramp. Our team has accessibility checks as part of our Definition of Done – the task hasn’t passed testing until it’s passed accessibility testing. The deck at Shake Shack gets picnic tables and market umbrellas for lovely weather. One day, while there for lunch, we noticed that one of those market umbrellas was placed right at the top of the ramp. Because Shake Shack is mean and wanted to make sure no wheelchairs could access their restaurant? No. Just a little bit of inattention. 44

slide-46
SLIDE 46

Those resources again, in case you’re now sold on the importance of this effort. 45

slide-47
SLIDE 47

Gretchen Grant is a recovering English major who was saved by the web. Currently a senior front-end web developer at The Institutes in Malvern, Pa, she serves as an embedded scrum master and lead for the Thunder Ponies front-end web development team supporting a score of Drupal 7 and Drupal 8 sites. With “I fight for the user” as her motto, she advocates for best practices in User Experience and Accessibility and is leading the

  • rganization’s effort to become AA compliant across their web properties.

46