On Github hmig / Making-Awesome-Things-Accessible
Hi.
My name is Heather Migliorisi and I'm a Software Engineer for BlackHawk Network and I work on the GiftCards.com website.
Disclaimer...
Open source has an extended reach and greater impact than any kind of closed software today.
I can't find any hard numbers/statistics to back that up.
But, you see it used everywhere. I can't imagine not to using it.
Web Accessibility - A digital world for everyone, regardless of ability.
Web Accessibility means a digital world for everyone, regardless of ability.
The types of disabilities we need to be aware of are:
Let's start with vision
There are 3 types of visual classifications
1. Color Blindness
2. Low Vision ... Note - the majority of visually impaired are not completely blind...but have some sort vision impairment.
3. Blindness
!!!!!show video of blind man using iphone
The next classification is hearing
providing closed captioning and transcripts are very important for people with hearing loss
The next classification is Motor Disabilities
Motor Disabilities can be the result of either:
Traumatic Injuries, Diseases or Congenital Conditions
There are a lot of different types of Assistive Technologies to aid people with motor disabilities.
Some not pictured are:
NOTE - Regardless, most assistive technologies either work through the keyboard or emulate the keyboard.
Cognitive Disabilities Include things like:
Things to consider for the web:
When it comes to content and features: KISS - Keep It Short and Simple
Clean designs
Easy to comprehend content
Avoid:
-content overload
-blinking animations (can induce seizures)
-things like carousels (that autoplay and cannot be stopped) and parallax can literally make people sick
Just because you don't fall into one of these classification today, doesn't mean you can't benefit from the solutions designed for those considerations.
Have you ever forgotten your headphones on the bus (loud and crowded) or tried using your device outside on a bright and sunny day?
things like transcripts/cc OR good contrast benefit YOU in those scenarios
Or have you ever had a broken an arm or had an ear infection?
Show of hands, who's NOT getting older?
Why should the open source community care about accessibility?
The reasons are the same for everyone regardless of open source or not.
BUT, the added benefit of open source projects being accessible is the reach you have and the exponential impact.
According to Census Data: Nearly 1 in 5 People Have a Disability in the U.S.
Opening your business up to 20% more of the population doesn't mean you'll make 20% more, but at least you won't be preventing it
Also - Businesses must comply with Section 508 when supplying Electronic and Information Technology goods and services to the federal government.
Title III of the ADA requires that public and private establishments provide reasonable accommodations to the disabled
the DOJ has stated that law applies online as well.
So - inaccessibility can lead to legal fees, settlement costs, and harm to brand/identity
How many people do you see using curb cutouts and elevators that are not disabled?
All of these folks are able to benefit from the features added for people labeled with having disabilities.
You can retain information better if you read and hear it at the same time.
So - reading the transcript of a podcast while you listen to it
And good contrast levels makes content easier for everyone to read
By using proper markup and the latest standards, the content becomes more flexible and easier to use tools to extract and present the information to users in different modalities (gym equipment, refrigerator, ...).
It's the right thing to do.
From the time we wake up until we go to bed.
We are on one device or another.
Socializing, emailing, working, repeat.
Even from a young age.
Could you go without using the web?
You go to buy the latest/greatest tech gadget, but a blank page is all that loads.
What if you tried going to your favorite site for your favorite online activity....
Annnd, you got a blank screen?
...the page is freaking out and filled unrecognizable errors
Or a ton of unrecognizable error messages...
that you couldn't close.
What if ... every site you went to was like this?
What if ... you could no longer use the internet you helped develop?
What if you had to ask someone to click buttons for you....?
At what point, do you give up?
Sadly, this is what much of the web is like for people with disabilities and giving up is not an option.
So, with open source having such a large reach and huge impact ...
let's do our part to fix this problem.
Since HTML2 (1995), the web was accessible by default
just text, links, images with alt text and simple forms
This is Yahoo from 1996. It is completely accessible.
So - 1995 - completely accessible internet
Generally speaking, common accessibility issues found on sites today:
Awesome tweet from Scott Jehl:
Accessibility is not something we add to a website, but something we start with and risk losing with each enhancement. It is to be retained.
Accessibility is NOT a feature, it's part of the foundation.
Think about building a house without a foundation....
...would you just shrug it off and say you'll add it later? What's that process look like?
Realistically, you'd probably never do that because it seems like it'd be more work than it's worth, right...?
That said, it's a lot of work to add accessibility to a something after it's already done.
One person* cannot make and maintain an accessible product alone.
*Unless this is a tiny, one person product/project.So it's incorporated into the process:
Content Strategy UX/Design Development QA TestLet's look at this from the who does what approach.
In order for anything to be successful, it needs to be a part of the product goals.
Supported from end to end, starting with the product owner/ceo (person in charge) and ending with consumer touch point.
The four main guiding principles of accessibility are:
Perceivable - provide content alternatives (images, audio, video)
Operable (without a mouse)
Understandable - clear and simple (writing and functionality)
Robust - works across many devices
Something everyone should know...
The four main guiding principles of accessibility are ... [and read list]
Content is King
...
Easy To Read and Understand Content so that people with learning disabilities can consume the content.
Accessible designs DO NOT have to look plain and boring!!!
They can be beautiful and interesting, but the constraint has to be factored in.
The key principle of web accessibility for users with color-blindness is: Perceivable: because they cannot see the difference between certain color combinations
Bad: Error Messaging Relies on Color
Meaningful Without Color
here, we have an example of a not-so-good error messaging system because it's not the easiest to understand without color.
Better: Message Conveyed With Icons
This is a better example with icons.
Moving content can also be a annoying and distracting for some people.
For people with ADD, it makes it difficult for them to concentrate on other parts of the Web page.
But - for others it can trigger dizziness, nausea, migraines AND even seizures (epilepsy)
If you want to use these types of features, provide a way for users to turn them off easily.
PLAY VIDEO!!!!
ARIA - Accessible Rich Internet Applications -
ARIA - Accessible Rich Internet Applications -
This standard allows developers to set roles, states and properties on html elements
defines methods to make Web content and Web applications more accessible to people using assistive technology
If you can use a native HTML element or attribute, do it. - straight from the w3c
❮button role="button"❯ button text ❮/button❯
❮input type="text" required aria-required="true"❯
❮div hidden aria-hidden="true"❯
❮h1 role="heading" aria-level="1"❯heading text❮/h1❯
What this means is that, where implemented, the browser will expose the default implicit semantics of the element so you don’t have to.
❮header❯ maps to role="banner"
❮nav❯ maps to role="navigation"
❮main❯ maps to role="main"
❮section❯ maps to role="region"
❮article❯ maps to role="article"
❮aside❯ maps to role="complementary"
❮footer❯ maps to role="contentinfo"
BUT IE and Safari do not offer support for all of the role mappings. -Deque University
❮header role="banner"❯
❮nav role="navigation" ❯
❮main role="main" ❯
❮footer role="contentinfo" ❯
Read List
Now that we understand ARIA, let's start auditing!
We test using the w3c validator.
this one step will catch a multitude of sins
Warnings vs Errors
Errors - required to fix to validate
Warnings - are more of you may or may not need to fix -> more of a recommendation
<a href="#" onmouseover="dropdownmenu()">Products</a>
<button onmouseover="dropdownmenu()" class="btn-primary">button</button>
When you validate your site via W3C, you'll catch embarrassing errors like unsemantic html
Heading tags are for content hierarchy (outline), not for styling If you want an h3 to look like an h4, style it with CSS, but don't skip heading levels. If you don’t like how a button or link looks, style it with CSS. If it navigates, it is a link. Use link markup with a valid hypertext reference If it triggers an action, it is a button. Use a BUTTON element DIVs and SPANs are not buttons and are not natively supported to have keyboard focus, name, role, or value ... why use them and have to add all of this support via more code?DO NOT add a tabIndex that is greater than 0.
Add a skip nav (and make sure it works!) -- add tabindex=-1 to elements you want to be focusable, but not in the normal tab order
Add a skip nav (and make sure it works!) -- add tabindex=-1 to elements you want to be focusable, but not in the normal tab order
Add other skips or simply set a negative tabindex for elements that are redundant
<svg version="1" id="cat" viewBox="0 0 720 800" aria-labelledby="catTitle catDesc" role="img"> <title id="catTitle">Pixels, My Super-friendly Cat</title> <desc id="catDesc">An illustrated gray cat with bright green eyes that is waving it's tail.</desc> <path id="tail" data-name="tail" class="cls-1" d="M545.9,695.9c8,28.2,23.2,42.3,27.2,46.9,21.4,24.1,41.5,40.2,81.1,42.9s65.4-14.2,60.8-26.8-23.1-9.1-51.3-8.3c-35.2.9-66.6-31.3-74.8-63.9s-7.9-63.8-36.8-85.5c-44.1-33-135.6-7.1-159.8-3.4s-48.4,52.5-9.6,45.1,91.4-23.1,123.2-12.7C537.8,640.4,537.9,667.7,545.9,695.9Z" transform="translate(-9.7 -9.3)"></path> <g id="head"> ... </g> </svg>
text inside of a canvas element with paragraph tag
<canvas>text inside of a canvas element</canvas> <canvas><p> text inside of a canvas element with paragraph tag </p></canvas>
When using canvas you must provide content that conveys the same function/purpose as the bitmap canvas.
It can be as simple as providing text in the canvas. The text is not visually seen, but is read via the screen reader.
//hiding text elements from the view, but keeping them available to the screen reader .sr-only { position: absolute !important; height: 1px; width: 1px; overflow: hidden; clip: rect(1px, 1px, 1px, 1px); clip-path: polygon(0px 0px, 0px 0px, 0px 0px, 0px 0px); //for clip being deprecated }
<label for="email">Email Address</label> <input id="email" type="email" placeholder="Email">Don't forget to label things that have hidden labels (search box). Use .sr-only class that is used for the icon fonts.
<label class="sr-only" for="search">Search for Gift Cards</label> <input type="text" id="search" placeholder="Search for stuff">Put the label/input group in a li tag and put all of these groupings in a list. Check out: Falling in Love With Forms by Aaron Gustafson
Document best practices and provide:
Document best practices and provide:
testing
Demo a few of these...
Ask for a site to test...
Some companies are even providing developers with Accessibility Labs - Yahoo, Comcast, Facebook & Google
So - developers can try out the devices and methods and figure out how to create better experiences.
------Next slide--------
BUT - you can never replace seeing the real user experience.
It's always eye-opening to conduct user testing.
You never think somethings really "that bad" ... pause ...
Until you realize someone has to have someone else to click a button for them because they cannot access it.
You will see a different internet.
Think of it this way: you wouldn’t want a designer or developer to do usability testing by testing the design or code on themselves. ... They’re already familiar with what problems the design is supposed to be solving, and how the interface works. - Jeremy Keith