Making your website accessible for users with disabilities isn’t flashy, but it’s necessary. Websites built for universal access benefit all users, not just users with a disability. They’re also more SEO friendly, and are generally built to be more user friendly. From generating increased revenue, to providing better access to services, the benefits of developing accessible websites are real and measurable.
The State of Georgia recently completed an Accessible Platform initiative, reviewing the templates and themes for our enterprise Drupal platform for accessibility gaps, and launching rolling improvements to the platform over several months to meet WCAG 2.0 (Level AA) compliance levels.
Accessibility doesn’t have to be an additional step in the web development process. Out of this initiative came a number of lessons learned on how code can be written to be accessible from the beginning, to mitigate the need for such cleanup efforts in the future. Building websites with accessibility in mind from the start saves time and money in the long haul. By following best practices for front end development, accessibility can be a seamless, invisible step in the build process.
7. Accessible websites are
Search Engine Friendly websites
Search Engines :
Can’t “see” images
Can’t “hear” audio
Can’t interpret audio or video from a movie
Can’t interpret color-coding or graphic
representations
8. Use a text browser, such as Lynx, to
examine your site. Most spiders see your
site much as Lynx would. If features such
as JavaScript, cookies, session IDs, frames,
DHTML, or … Flash keep you from seeing
your entire site in a text browser, then
spiders may have trouble crawling it.
Google Says:
https://support.google.com/webmasters/answer/40349
“
”
11. How Large?
● 15% of the population has some form of
disability
● 7 to 10% of men have some form of color
blindness
● 4% of the population have low vision
Access by Default #GWO2016 @kskeene
12. Low Vision Conditions increase with Age
● 1/2 of people over 50 have a low-vision
condition
● Most people over 40 need reading glasses
to clearly see small objects or text
The fastest-growing population in the US is
over 65 years of age.
13. Our Population is Aging
15% of US population is over the age of 65
source:www.pewglobal.org/2014/01/30/global-population
2015 projection
65 and older: 14.7%
15-64: 65.9%
Under 15: 19.4%
Total: 100%
21. Enterprise Web Platform
- Managing over 75 state websites
- more than 400 content managers maintain
content
Georgia.gov (different codebase)
- managing code AND content
23. Section 508 Accessible Websites
● Drupal 7 Platform
● Omega Base theme
● Child themes tested for accessibility
● No frames
● No flash
● Fields for image alt text
● Fields to label tabular data
● Webform labels
29. Accessible Platform Code: Result
24 code improvements
● link text
● tabbing visibility
● structural HTML and
heading order
76 sites
improved
30. Now for the really
tedious part...
Access by Default #GWO2016 @kskeene
31. We reviewed every
element of every theme
for color contrast
and font legibility
Access by Default #GWO2016 @kskeene
32. Accessible Platform Themes
Using Common Tools:
● Google Chrome
○ FontFace Ninja
○ ColorZilla
● WebAIM Color Contrast Checker
● Google Spreadsheet
Access by Default #GWO2016 @kskeene
46. 1. Color me accessible
Access by Default #GWO2016 @kskeene
47. Color Contrast
4.5 : 1 color contrast ratio
http://contrast-finder.tanaguru.com/
http://leaverou.github.io/contrast-ratio/
http://webaim.org/resources/contrastchecker/
Access by Default #GWO2016 @kskeene
48. Color Testing
Test usability against color loss
NoCoffee Vision Simulator for Chrome
Access by Default #GWO2016 @kskeene
50. Build in color contrasts
checkers for tools that allow
users to select their own colors
Building the Tools:
Access by Default #GWO2016 @kskeene
51. 2. Type - Size Matters
Access by Default #GWO2016 @kskeene
52. Typography - Size Matters
●Text should be 1em or larger
●Use relative units instead of pixels
●Increase line height - 1.2em - 1.6em
●Increasing text size by 200% should not
break your layout
53. DON’T USE ALL CAPS.
SCREEN READERS WON’T READ
THE WORDS CORRECTLY.
ALSO, IT’S HARDER TO READ FOR
SIGHTED VIEWERS, BECAUSE
THERE’S NOT ENOUGH VARIATION
IN THE LETTERS.
Access by Default #GWO2016 @kskeene
54. Touch Targets - Bigger is Better
●make touch targets as large as is
reasonable
●at least 9mm high x 9mm wide
●surrounded by inactive space
56. Alt Attributes for All Images
Alt text for images that provide value or
context to the information
Null alt text for decorative images
<img alt="" … >
57. To Alt, or Not to Alt?
Decision Tree:
https://www.w3.org/WAI/
tutorials/images/decision-tree/
Access by Default #GWO2016 @kskeene
58. ● Provide a field for alt text
● Use help text to guide
content managers
● Don’t make alt text required
● Default to alt="" if no alt
text is entered
Access by Default #GWO2016 @kskeene
Building the Tools:
59. Text Representation for Glyphs
Provide hidden text for glyphs
and icons that aren’t images
(e.g. Font Awesome icons)
60. Speaking of Hiding Elements...
DON’T use:
● visibility: hidden;
● display:none;
● width:0px, height:0px
● text-indent: -10000px;
Hides text from
screen readers,
too (whoops!)
focus box issue
when tab focus
is on the link
61. Speaking of Hiding Elements...
DO use (when hiding entire element)
position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
remove from the page flow
and position off-screen
backup in case
positioning is disabled
prevents left from
being ignored
62. Speaking of Hiding Elements...
DO use
(when hiding text but keeping other elements)
text-indent: -10000px;
overflow-y:hidden;
Moves just the
text off-screen
fixes the Firefox focus box
issue when tab focus is on
the link
63. 4. A Matter of Semantics
(markup, that is)
Access by Default #GWO2016 @kskeene
64. A Tag for Everything, and
Everything in its Tag
Use tags for their specified purpose
● don’t use a <div> for a <button>
● <blockquote> is for quotes,
not indenting text
65. Heading Tags - Right Place, Right Time
● Use H1-H6 tags for headings only
● <h1> for the main heading of the page
● Sequence Matters:
<h6> should only come after <h5>,
which is after you use an <h4>, which is
nested under <h3>, which should follow
<h2>, which is nested under <h1>
66. Provide users with an option
to choose the heading level
for module headings for
blocks that can be placed in
different locations on a site.
Building the Tools:
Access by Default #GWO2016 @kskeene
72. Useful Link Text
●Provide relevant link text
●WAI-ARIA attributes can add helpful
text
○ aria-label
○ aria-labelledby
73. ARIA Labels for Useful Link Text
<a href="/underwater-datacenter">
Read More</a>
74. ARIA Labels for Useful Link Text
<a href="/underwater-datacenter"
aria-label="Read more about
Underwater Datacenters">
Read More</a>
75. 6. ARIA fills in gaps
Access by Default #GWO2016 @kskeene
76. ARIA Landmark roles
HTML attributes that provide “landmarks”
for screen readers navigating a page
●<header role=“banner”>
●<div role=“search”>
77. 7. Form and Function
Access by Default #GWO2016 @kskeene
78. Forms
● Each form field needs a <label>
● Place any help text between the <label>
and <input> fields
● Use <fieldset> to group related fields
79. Forms
● Indicate required fields with * (not just color)
● Clearly mark fields with input errors
(not just using color)
● Check tab order
(fix with tabindex if needed)
81. Tables for Tabular Data
● use <thead> to mark the table header row
● mark header cells <th> instead of <td>
● <caption> describes the data - like a title
82. 9. Javascript
(I’ve got nothing witty
for this one, sorry.)
Access by Default #GWO2016 @kskeene
83. Javascript is not Evil
●JS should enhance the experience -
but not be the only path to content.
●Don’t use inline Javascript
●Provide fallbacks
●tools like ally.js can help
good morning
honored to have you join me
lot of choices with what to do with your time, so aim to make it worthwhile.
Director of Product for the state of Georgia’s enterprise Drupal platform.
This past year, I led the platform enhancement efforts for our Accessible Platform initiative.
[pause]
We serve two different groups - we serve state agencies, serve all the constituents of Georgia
champions for the visitors
What features and choices best serve the audience?
To that end, we’ve turned our focus on increasing the accessibility of the platform
This isn’t the sort of response I expect
It’s not fun and flashy, like new CSS animations, ordering pizza with an emoji, or underwater datacenters ....
You’re not likely to even SEE the results of the work - which is how so many developers get away with ignoring it altogether.
But the benefits of making your code accessible are real and numerous. And they’re not all that difficult to integrate into your code from the outset.
In fact, I would argue that developing for universal access benefits all users, not just users with a disability.
I would even go so far as to say that coding for universal access now will benefit you in the future.
Today, I’ll unpack:
why universal access matters (the carrot AND the stick)
what the state of Georgia has done to make its enterprise web platform accessible, and
Easy wins to make sure you include accessibility into your code from the start
**will be tweeting resource links
When we speak of “disabilities” we typically think of blindness and deafness, but:
Visual disabilities,(blindness, low vision, color blindness.) Auditory - range of hearing loss.
Motor skills. (mouse, keyboard, touch screen, voice-activated, FATIGUE).
Cognitive disabilities, (problem-solving, visual comprehension, dyslexia, memory loss.)
Remember that seizures can be triggered by flickering, blinking, or moving text.
Now that we have a baseline of what we think about when coding for universal access...
Why make your markup accessible?
You’ve chosen to sit here today, so it’s likely that I’m preaching to the choir when I say accessibility is important.
But I want to hit some key points on it - maybe some will help you convince stakeholders that you should put the time into it.
So how do you sell an accessible code strategy to your stakeholders?
You can take the carrot, or the stick approach.
First, the carrot.
Accessible code and content is SEO friendly -
search engine spiders are the ultimate “screen reader” user.
Google even says:
“Use a text browser, such as Lynx to examine your site, because most search engine spiders see your site much as Lynx would. […] If fancy features such as JavaScript, cookies, session IDs, frames, DHTML, or Flash […] keep you from seeing all of your site in a text browser, […] then search engine spiders may have trouble crawling your site.”
so screen reader friendly = Google friendly
Accessible sites are more user friendly - when you focus on making features easy for users with motor skill challenges or cognitive disabilities, you’re really making them easier for everyone to use.
Users with disabilities are a large audience you may miss out on otherwise.
Your web analytics aren’t going to report on any of this, though.
So we have to take an educated guess at the percentage of visitors who will benefit from accessibility enhancements.
15% of world population has some form of disability
7-10% of men have a form of colorblindness
4% of the world population has a low-vision disability
What’s more, low vision conditions increase with age.
1/2 of people over 50 have a low-vision condition, and
Most people over the age of 40 at least need reading glasses to clearly see small objects or text.
Fastest-growing population is over 65 years of age.
These facts should affect our thinking about accessible code in a couple of ways - one is in thinking about your user base.
Currently, 15% of the US population is over the age of 60, and that projection continues to grow, with 20% of the population projected to be over 65 by 2030.
And now it starts getting personal. This should come as no surprise to you - we’re all getting older.
If you don’t have a disability now, you probably will be in the future (we’re all Temporarily Able Bodied).
I know you - you’re a techie. You’re going to want to be just as connected to technology then as you are now.
If we work to make sure accessible code is built into the projects we work on now - if Universal Access to technology becomes “the norm” - we’ll all benefit from it when we need it in the future.
(If you won’t do it for someone else, do it for yourself!)
But let’s be honest. The main reason companies are sitting up and taking notice of accessibility is due to the Stick approach.
The Stick:
If your code isn’t accessible, you might get sued.
In recent years, the Department of Justice has based their settlements on conformance to WCAG 2.0 Level AA guidelines. This is also what the Section 508 Refresh is being based on, which will likely be updated and become law some time in 2016.
many school systems, government entities, and private companies have been sued for inaccessible websites, with settlements requiring them to meet WCAG 2.0 Level AA guidelines
This also means more companies are getting wise to the need (or at least the risk of litigation) - and are looking for developers who know how to build accessible sites and apps
now that you have the Whys, let me tell you a little bit about what we did for the Georgia web platform
My team at GeorgiaGov Interactive maintains the state of Georgia’s enterprise web platform.
We maintain a Drupal 7 platform with a common codebase for over 75 state websites -
basically we handle the technology, the code, maintenance, and support.
The agencies are responsible for the content that goes on their sites, but we handle the rest.
We also own and maintain the state’s web presence at georgia.gov, including its content.
At GeorgiaGov Interactive, we believe that government has a responsibility to be accessible.
If our websites aren’t built with accessibility in mind, it creates real barriers to some of the users who need them the most.
In fact, when we built our Drupal platform, our vendor did some extensive accessibility testing on the code as they went - focusing on Section 508 compliance. They made adjustments during the initial build, specifically with tab order and interactive form fields.
So when we launched the platform, we were pretty proud of ourselves.
But as we talked to a group out of Georgia Tech who focuses on accessible technology outreach, we learned
... our work wasn’t done.
There were still a lot of things that the initial accessibility testing didn’t look for.
So we partnered with the state ADA’s office and AMAC Accessibility to form AccessGA, a joint initiative
with the purpose of providing outreach and training to state agencies to help them meet accessibility standards.
With funding from the ADA’s office and the expertise of AMAC, we were off and running with a plan to audit our sites.
The group audited our sites against the WCAG 2.0 (Level AA) compliance standards.
We provided them with URLs of pages that contained different elements of our platform, with the intent of catching as many variants as we could with as few pages as possible. They provided us with 13 reports, which covered all 13 themes, and evaluations of different content across 33 page types (and even more types of page content).
Out of that gap analysis, we dug into the recommendations, came back with questions for followup where we were uncertain about the recommendations,
and ended up with a list of enhancements we were able to address.
Then, from July 2015 - Jan 2016, the team completed
24 platform code enhancements
And by “the team” I pretty much mean the awesome Jenna Tollerson (clap)
We were also able to commit some of our improvements back to the shared modules on Drupal.org. (Isn’t open source great?)
We also did some internal testing against all the variations of text colors on each theme to identify where they failed for color contrast, and then
created new color palettes for each theme, and updated them
We used Fontface Ninja and Colorzilla to grab font size and color data straight from the screen in Google Chrome, and we compiled it all on a shared Google spreadsheet. We used WebAIM’s Color Contrast Checker to report on contrast ratios.
So once we set it up, it was a fairly quick process to gather the information. When this was done, we had a good picture of what we were working with, and our designers went to work coming up with new color palettes.
We tried to stay true to the originals as much as possible, but with color contrast sometimes that was easier said than done.
Once the new color palettes were reviewed and approved, our UX Developer updated the code on our staging environment, and we performed further testing of the themes in staging.
Once the new color palettes were reviewed and approved, our UX Developer updated the code on our staging environment, and we performed further testing of the themes in staging.
The result?
that’s a lot of improved state websites. We’re pretty excited about it. While I’m beating the drum of a more accessible platform,
I can’t help but think -
we could have done all of this in the first place. We just improved the color contrast in 13 themes to make them easier to read for users with impaired sight - but why weren’t they designed that way from the beginning?
Honestly, the answer is ignorance.
We just didn’t know.
All the able-bodied designers and developers thought if WE could use it, so could anyone else. Our vendor’s accessibility testing evaluated for users who had lost their sight completely, but not users whose vision was impaired, for whom improved size and contrast would make all the difference. We weren’t evaluating for the approx 10% of users who have some form of colorblindness.
And that is why I’m standing in front of you today. Not because I’m an accessibility expert - I’m not. But because I want to share what I’ve learned so that you can build accessible the first time around.
So enough with the background. Let me give you some quick wins on what you can do to code your sites, applications, and modules for universal access by default.
We’ll be looking at how to make some quick wins when thinking about :
If you get an urgent work call in 3 minutes and have to leave the rest of my talk, I want to make sure you leave with this one new tool in your “quick wins” toolbelt The A11Y Project has a FANTASTIC checklist to reference to help you hit all the quick wins. If you walk away with nothing else from this talk, but you start referring to this list as you work, I’ll consider this a success. http://a11yproject.com/checklist.html (but they have a ton of other great resources on that site, too. Many of you will geek out over their http://a11yproject.com/patterns/ Patterns library).
Now for those of you who don’t have urgent calls, I can go into more detail on some things you should be focused on.
First, let’s talk color. This is something that starts at the design phase - making sure your color palettes have enough contrast, and your text is large enough to be legible to your broader audience. But it should’t end there. Everyone should keep the question of color in the back of your minds as you go - remember, nearly 10% of the population has some sort of color blindness alone.
WCAG 2.0 level AA requires a 4.5:1 color contrast ratio for normal text, 3:1 for larger text to meet the needs of a variety of low-vision conditions.
There are a variety of tools out there for testing for color contrast, and they each serve different purposes.
Once your designs have been tested for color contrast, you should also review them for usability against a number of color differences. The NoCoffee Vision Simulator for Google Chrome will give you a browser experience with a variety of vision impairments, so you can see if your design still communicates without the benefits of color.
Here’s an example of how the NoCoffee simulator can show you how others may see the colors on your websites
If you’re in the position to build a tool that allows a content manager to select and change their own colors, you can really advance the awareness of accessible color palettes if you build in color contrast checking into the web tools you’re providing.
of course, text size matters, too. (We’re all getting older.)
Avoid All Caps in sentences, and not just because it’s impolite to yell. Screen readers will read some all-caps words letter-by-letter instead of as a full word, so it distorts the meaning of the sentence. It also makes the text harder to read for sighted visitors, because there isn’t enough variation in the letters.
similarly, when thinking of your touch targets
Any image that is adding value to the content of a page should have brief, useful alt text.
However when an image is used purely for decoration, the alt text can be left empty so that the screen reader user is not distracted from the more important content on the page. alt=”” (some content management tools do this for you when you leave an alt text field blank).
Why provide null alt text, instead of just skipping the alt field altogether for decorative images? Because without the alt=””, many screen readers will read off the image title instead - which, as you might imagine, can be super painful to listen to when image filenames are machine generated or human-abbreviated.
W3.org has a great decision tree to help you determine when to use alt text or when to leave it null.
For example, if an image has a visible caption explaining it, you don’t need alt text, too. That’s just overkill.
If you’re the one building the tools for others to insert images or icons, you’re not off the hook yet. With great power, comes great responsibility. Be sure to provide a field for alt text - but don’t make it a required field. Remember, sometimes alt text should be null - so build that in, too. a blank alt field should generate an alt equals null HTML attribute.
Alt text for icons (including glyphs and font icons, e.g. font awesome)Similarly, as you start moving away from images and toward iconsets such as font awesome glyphs and emojis, be each glyph should be accompanied by hidden descriptive text that is available to the screen reader, but invisible to the browser.
speaking of hiding elements...
some methods are better than others.
These methods will hide text from the screen readers, as well
Another key way to make your code accessible is to use semantic markup correctly. Again, you probably already know some of this, but other rules of semantics may seem less obvious
If you’re the one building modules or widgets that may live in different places on a website, see if you can give users the option to select what heading tag value your module uses. This was a huge struggle for us when using 3rd party drupal blocks - we have to modify them to use the correct heading tag, or in some cases settle for not using the right heading level at all.
now let’s talk about the links that connect us all.
as much as we need our links, sometimes you need to skip past all the navigation at the top to get to the good stuff.
To make that easier for keyboard users and screen readers, Include a Skip to Main link that’s hidden on screen until you move tab focus to it
don’t open links in a new window UNLESS there’s a good reason - like opening a help window that should be shown along with the other text, or loading a PDF.
To users not expecting it, links opening in a new window seem to disable the Back button
Don’t remove :focus outlines on your links. Tons of people use their keyboard to navigate, and :focus provides the visible border to element that allows users to see where their keyboard focus is. Some polyfills set :focus to outline:none; which makes it harder to turn it back on for just the elements you need - case in point, trying to add a focus outline across the board will make IE put an outline around any non-link element you click on the screen.
We ran into a lot of problems when we turned tab focus back on - issues in IE, other issues in Firefox - so be sure to test across browsers. (Safari doesn’t focus on links at all unless you option-tab, which was extra confusing during testing). ally.js may help with your focus woes, though our team doesn’t have experience with it.
Provide USEFUL link test. Link text should be used to inform users of where the link will be taking them. Be as descriptive as possible to avoid confusion and frustration. Clicking the “back” button in your browser may not seem like a complicated task for many of you, but for physically or visually impaired users, it may not be so simple.
Also, screen readers allow visually impaired users to navigate webpages via a list of internal links, so ten links all titled “Click Here” would be of no help.
And it helps your SEO. Link text also informs search engines of where links are headed. Search engines like Google are rewarding sites which provide high-quality content and links to other reputable sites, so providing this level of description of where a link goes can really help there, too.
Whenever it makes sense, the link text should be descriptive. We ran into some instances, however, where it would have been redundant to have links that visibly repeated the title of the page it was linking to - for instances like where a visible Read More really does make the most sense, you can use WAI-ARIA tags to make those links more descriptive for screen readers.
(aria-label example)
(aria-label example)
speaking of ARIA attributes, they can fill in some assistive technology gaps that the rest of our markup doesn’t address
Speaking of ARIA, there are some other accessibility-specific landmark attributes that can help you markup the structure of your site for more complicated layouts.
Forms functionality is super important because it’s how we can interact with each other online.
I don’t need to tell you that tables aren’t for layout. But I may need to remind you that tables, at their core, are not inherently evil.
They SHOULD be used for tabular data. In that form, they’re HIGHLY accessible. Just remember to label table header cells, and provide a descriptive caption of what the table shows.
Lastly, javascript is not evil. Most screen readers actually read javascript, so don’t assume they won’t encounter it at all.
BUT javascript can certainly be used for evil - take care not to use javascript as the only way to experience the site. Is should be used to enhance the experience, not as the only way to experience a site.
Because some the devices don’t use javascript, it’s important not to use inline javascript instead of natural interactive elements - for submitting a form, for example - and provide fallbacks so all users can use your tools.
Alright! I’m pumped! Accessify all the things!
wait, shoot, that’s a lot. I still don’t know where to start!
The point is to start somewhere, right? I’ve tweeted links to some resources today, and I’ve also put together a list of useful resources to get started on my website
takes work, takes thought, but we can do it - and it’s worth it. The point? Build it into your process. Learn the basics and make it your default working process.
Let’s make our code accessible by default, not an afterthought.
thank you