Access by Default
•9 likes•4,372 views
Report
Share
Download to read offline
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.
More Related Content
What's hot
![Web Standards: Fueling Innovation [Web Design World Boston '08]](https://cdn.slidesharecdn.com/ss_thumbnails/web-standards-fueling-innovation-1228796603037960-8-thumbnail.jpg?width=384&fit=bounds)
What's hot(20)
![Web Standards: Fueling Innovation [Web Design World Boston '08]](https://cdn.slidesharecdn.com/ss_thumbnails/web-standards-fueling-innovation-1228796603037960-8-thumbnail.jpg?width=768&fit=bounds)
Viewers also liked
Viewers also liked(20)
Similar to Access by Default
Similar to Access by Default(20)
More from Kendra Skeene
More from Kendra Skeene(6)
Recently uploaded
Recently uploaded(13)
Access by Default
- 1. Access By Default Accessible code is better for everyone
- 2. Kendra Skeene @kskeene Director of Product GeorgiaGov Interactive @GeorgiaGovTeam
- 4. Why universal access matters What we did at GeorgiaGov Easy wins for accessible HTML Access by Default #GWO2016 @kskeene
- 5. Disabilities come in many Forms Visual Auditory Motor Skills Cognitive Seizure
- 6. Why? Access by Default #GWO2016 @kskeene
- 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 “ ”
- 9. Accessible websites are User Friendly websites Access by Default #GWO2016 @kskeene
- 10. Users with disabilities are a large audience Access by Default #GWO2016 @kskeene
- 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%
- 14. Access by Default #GWO2016 @kskeene
- 15. We’re all Temporarily Able-Bodied Access by Default #GWO2016 @kskeene Coding for universal access to technology benefits all of us in the long term.
- 17. Department of Justice basing settlements on conformance to WCAG 2.0 (Level AA) guidelines Access by Default #GWO2016 @kskeene
- 18. Department of Justice Rulings ● edX ● Carnival Cruiselines ● SAM.gov ● Seattle Public Schools … and so many more
- 19. What We Did Access by Default #GWO2016 @kskeene
- 20. Community Health Veterans Service Governor’s Office Attorney General Public Safety Dept. of Labor Technology Authority Dept. of Revenue Human Services Environmental Protection Planning and Budget Inspector General Access by Default #GWO2016 @kskeene
- 21. Enterprise Web Platform - Managing over 75 state websites - more than 400 content managers maintain content Georgia.gov (different codebase) - managing code AND content
- 22. Government has a responsibility to be accessible Access by Default #GWO2016 @kskeene
- 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
- 24. But we weren’t there yet
- 25. But we weren’t there yet
- 26. Accessible Platform Initiative WCAG 2.0 (Level AA) compliant code and design
- 27. Accessible Platform Initiative Partnership with AMAC to find the gaps AMAC provided 13 reports across ●13 themes ●33 page types
- 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
- 35. Before
- 36. After
- 37. Accessible Platform Themes: Result 13 themes updated ● color contrast ● text legibility 76 sites improved
- 38. WCAG 2.0 (Level AA)!
- 40. Why didn’t we do all that in the first place? Access by Default #GWO2016 @kskeene
- 41. Access by Default #GWO2016 @kskeene We didn’t know.
- 42. Access by Default #GWO2016 @kskeene
- 43. What You Can Do Access by Default #GWO2016 @kskeene
- 44. Quick Wins - Think About: 1. Color 2. Type 3. Images 4. Semantics 5. Links Access by Default #GWO2016 @kskeene 6. ARIA tags 7. Forms 8. Tables 9. Javascript
- 45. Quick Wins - Checklist A11Y Project Checklist http://a11yproject.com/checklist.html 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
- 49. Color Testing
- 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
- 55. 3. Image Descriptions Access by Default #GWO2016 @kskeene
- 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
- 67. 5. Links Connect Us Access by Default #GWO2016 @kskeene
- 68. Links Use a “Skip to Main Content” link that’s hidden until tab focus is on it <a href="#main-content" class="skip">Skip to Main Content</a>
- 69. Links Just Say No to target="_blank"
- 70. Links Don’t remove :focus outlines ● ally.js can help you :focus http://allyjs.io/
- 71. Useful Link Text Read More Apply For Child Support ✗ ✓
- 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)
- 80. 8. Table it Access by Default #GWO2016 @kskeene
- 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
- 84. Accessify all the things!
- 85. Accessify all the things?
- 86. Resources http://idreaminblue.com/accessible-resources/ ● Checklists & Guides ● Color Contrast Testers ● Drupal Resources ● Vision Simulators ● Open Source Accessibility Testing Access by Default #GWO2016 @kskeene
- 88. Access By Default Accessible code is better for everyone
- 89. We’re hiring! Drupal Solutions Analyst contact me: @kskeene
Editor's Notes
- 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