Press "Enter" to skip to content

Getting Down and Dirty with Accessibility and Usability – #TCUK12 Workshop

Published 2 November 2012

These are the notes from my workshop on 2 October 2012 at the Technical Communication UK (TCUK) 2012 conference. I called it “Getting Down and Dirty with Accessibility and Usability”. Unlike the slides for my keynote presentation at the same conference, the slides in this workshop were text heavy. (Slides are at the bottom of this post.) They were meant as notes – talking points – for the workshop. Each slide covers areas where technical communicators can begin to apply accessibility and usability right away.

The workshop was called hands-on, but I ended up talking for most of the session because many attended out of curiosity and had no actual projects for hands-on practice. There were many great discussions and questions and answers during the 2.5 hours of the workshop. (If any my TCUK12 workshop attendees come to TCUK13 and want to discuss accessibility “hands-on”, we can always hack in a corner of the bar! My treat!)

Due to the poor accessibility on Slideshare – presenter notes aren’t pulled out for the transcript, I am posting my own notes here (with the slide text for context). Other presenters express frustration about the downside of sharing slides. There is often little context and image-heavy slides can be meaningless even to people with sight.

I had extra slides so I wouldn’t run out of material. These are marked as such.

Introduction – Slides 2, 3, 4, 5

Today’s workshop. The pretty pictures are on your screens, not in these slides! What can be fixed right away and how? Where can you find more resources? We’ll look at what accessibility and usability tricks you can put in your toolkit. We’ll also discuss ways you can apply your new skills – I used the logo of TCUK to symbolise the field of technical communication. Finally, I had to be slightly corny and mention “enlightenment” – the dawning of new knowledge in the minds of many more technical communicators. I used a personal photo of a winter sunset to illustrate this point.

I mentioned how it all just takes one step at a time to implement accessibility. Here’s an article that demonstrates the one-step-at-a-time approach.

BAD Demo – Slide 6

The Before-and-After Demo from W3C: http://www.w3.org/WAI/demos/bad/

. This is an excellent training/teaching resource. I had it downloaded on my laptop in case the wifi didn’t work. It demonstrates a site without and then with accessibility improvements. I referred to it a few times during my presentation. Kudos to the people in the Education and Outreach Group at the Web Accessibility Initiative who developed this great resource!

Good examples of accessible websites – Slide 7

For inspiration.

Alt text – Slide 8

I always point everyone to these links. They explain everything. Written by smart people!

And remember alt="" (Read the links to find out what that means.)

I had one more reference from @vdebolt with tips on using appropriate alt text that some of you might enjoy.

Title attribute – Slide 9

<title> is a misused attribute. Get the low-down in this excellent link:
Using the HTML title attribute

Longdesc – Slide 10

The <longdesc> is going through turbulent times, but I say go for it. There is a good article on longdesc from WebAIM.

I listed tables on my slide, but that was a mistake. Just read the article and you’ll get it straight. For more food for thought, read RNIB’s article on longdesc from 2008.

Jim Thatcher made a marvelous favelet tool for checking web accessibility. You can try it for checking longdesc, too. (I haven’t tested that.)

Headings and Structure – Slide 11

This should be an easy one for technical communicators. Use headings! Use structure!
My talking points were

  • Logical!
  • Skip to main content links (blind and keyboard users)
  • Sequence and patterns (non-linear navigation – reading order)
  • Style guides (for consistency)
  • ARIA

My support notes:Note that screen reader is only interested in HTML, not CSS, therefore structure (web standards) is important. Headings are the easiest way to identify structure. Proper structure and good use of headings aid navigation. Use semantic markup and good navigation. Keep things logical. Visual readers interpret the graphic presentation for navigation: headers, location, etc. A screen reader needs similar info because screen reader users need the same thing for navigation.

ARIA is especially helpful (more links later). There are 8 document landmark roles to help screen reader users navigate and identify purpose of content as explained in article on WAI ARIA document landmark roles.

Skip to main content links – beneficial not only to blind, but to keyboard users who want to get to a link in the main article and want to avoid all the navigation and advertising links. This is a useful article about skip to main content links.

It’s a myth that vision impaired users access everything in a linear fashion or listen to everything on the page. They can skip around on a page (if the structure lets them) and it helps if there is a pattern. Vision-impaired users access things sequentially – learn layout and become familiar. Frequent layout changes must be a pain! VI (vision-impaired) users listen to all on-screen text – they can skip around, too, listening to just enough to decide whether to stay or go. Source on VI reading patterns.

BBC has a standards and guidelines semantic markup guide they use. You can base your own in-house style guide on that, for example, to ensure that everyone uses markup correctly and consistently: BBC guidelines for semantic markup.

Lists – Slide 12

Lists: <ol> , <ul> , <li> , and CSS styling

Always use <li> , <ol> , <ul> , and style with your CSS. Why people don’t do this, I don’t know. It’s clean! Rumor has it that this is a problem so I mention it to make sure you don’t make this mistake! Reference: WebAIM article on lists.

Keyboard-only access – Slide 13

Can you do everything with a keyboard? Everything? I use Hootsuite.com for scheduling tweets, but I am unhappy with certain inaccessible aspects of the product. I must use a mouse or I cannot complete the login procedure. Same problem with Tweetdeck (which I don’t use). I cannot log in with a keyboard. This is crazy when social media is proving to be a great and growing community for people with disabilities – mouse-only means many are excluded. I’m told only onClick works with both keyboard and mouse. Why not use classic HTML where possible? This can solve your mobile needs, too. Making everything keyboard accessible is a basic improvement that can go a long way.

Color – Slide 14

Remember that color and color contrast and alternate indicators play together. Never use color as your only delimiter. In Denmark, it’s estimated that 8% men are colorblind and 0.5-1% women are colorblind. (Danish resource on colorblindness stats in Denmark.) Moral: consider what colors you are using. This color contrast check from snook.ca is fantastic and very popular. Helps you determine whether you comply with standards, too. A keyword is contrast – watch out for color contrast. wearecolorblind.com is a great resource about color issues.

Labels – Slide 15

Labels need to be made correctly. Always identify the form field with an id attribute. Then, create a label element for each field. Connect it to the input field’s id using the ‘for’ attribute. I took the images on the slide from this video demonstrating coding labels for accessibility. Using placeholder in form fields is optional, but read this article for an opinion on why placeholder is a bad idea with labels.

Link text – Slide 16

DO NOT USE CLICK HERE OR READ MORE.

I rant the reasons why in my blog post I don’t want to read more or click here.

Plain Language – Slide 17 and 18

  • Design to Read
  • US: Center for Plain Language
  • US: Plain Language in the Federal government Plain Language in the Federal government and a Plain Language checklist
  • UK: Plain Language Commission

    • "How to Write Clearly" in 23 languages

    Text Size – Slide 19

    Tables – Slide 20

    Tables are for data. Not layout. Data. Make sure your tables are accessible. Because I don’t make tables regularly, I forget how to code them properly. I always have to look up the code, but I do look it up and make it accessible. Not doing so seems so wrong. The two resources here are a great help. Remember: use <summary> where you can also list number of columns and rows. Learn to love <th> element and <scope> attribute!

    Captioning – Slide 21

    I’ve given talks about captioning at TCUK10 and at the first a11yLDN unconference. I’ve pointed people to my presentation for captioning guidelines. Download the slides to get my presenter notes. They are vital – and not visible otherwise in Slideshare.

    Note: from slide 22 until my thank you at slide 35, I went very, very fast. I was running out of time and did want to close with the image on slide 34 and my closing credits. The slides are now getting heavier text-wise. They are meant as starting points for the topic in the slide header. I had so many resources for many topics. It was painful culling them!

    Video – Slide 22

    These are resources for accessible media players. Some are standalone players made to be accessible. The first link is a way to make YouTube accessible. The issue is that screen readers cannot access the controls for the typical media players, which means that they cannot access the video. And yes, blind people want to access videos to hear the information. Even a blind and deaf person could enjoy a video if it was captioned properly so there was an interactive transcript.

    Autoplay – Slide 23

    <autoplay="autoplay">
    DON’T USE AUTOPLAY! It’s hard or impossible to stop using screen reader. If a page is opened in a different tab, the sudden noise can be confusing, startling, or conflicting. I.e. cognition issues. (And that applies to everyone and anyone. DON’T DO IT!!

    ARIA – Slide 24

    These articles do all the explaining about ARIA.

    Testing and Evaluation – Slide 25

  • WAVE
  • Color Contrast and more – a Mozilla add-on
  • Fireeyes from Deque
  • Functional Accessibility Evaluator
  • Web Developer Extension from Chris Pederick
  • Web Accessibility Toolbar for IE from The Paciello Group
  • W3C WAI Tool List

    • There are many tools out there to help you evaluate your site. It is good to try them all at first and get a feel for what works best for you. Having a couple installed is not a bad idea. They can back each other up. These can catch the major bloopers. Use these tools to catch the low-hanging fruit. But… Never uninstall the best overall evaluation tool you have – your brain!! If testing excites you, consider joining the Browser Testing and Tools Working Group.

    In a comment on the page for the Web Developer Extension, I found this helpful video/article about using the tool. See also articles in the accessibility testing category from Karl Groves. And, finally, the achecker testing tool.

    PS WebAIM has a new WAVE in beta. Check it out at http://five.wave.webaim.org/.

    Screen reader testing – Slide 26

    Standards – Slide 27

    WCAG 2 at a glance – Slide 28

    Perceivable

    • Provide text alternatives for non-text content.
    • Provide captions and other alternatives for multimedia.
    • Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
    • Make it easier for users to see and hear content.

    Operable

    • Make all functionality available from a keyboard.
    • Give users enough time to read and use content.
    • Do not use content that causes seizures.
    • Help users navigate and find content.

    Understandable

    • Make text readable and understandable.
    • Make content appear and operate in predictable ways.
    • Help users avoid and correct mistakes.

    Robust

    • Maximize compatibility with current and future user tools.

    This one of many WAI teaching resources.

    WCAG 2.0 – Slide 29

    • Understanding WCAG 2.0: A guide to understanding and implementing Web Content Accessibility Guidelines 2.0
    • How to Meet WCAG 2.0: A customizable quick reference to Web Content Accessibility Guidelines 2.0 requirements (success criteria) and techniques.

    Learn-more resources – Slide 30 and 31

    Get to know how a screen reader works by reading the first article. The "Just Ask" link is an online book that is also available in print form. It is also a great way to start your journey into accessibility.

    The first two links are teaching/teach-yourself resources.

    The third link is an excellent newsletter that comes out every week. It comes highly recommended.

    The last link is the number one link I’d recommend to any technical communicator – along with the “Just Ask” book mentioned elsewhere here.

    10 Principles – Slide 32

    • Be equitable
    • Be flexible
    • Be simple and intuitive
    • Be perceptible
    • Be informative
    • Be preventative
    • Be tolerant
    • Be effortless
    • Be accommodating
    • Be consistent

    These ten principles were written by Sandi Wassmer and are in people-speak and another way to get the mindset for building accessibly. View the 10 principles of inclusive web design online where there is also a link to download a PDF.

    My favorite quote – Slide 33

    When universal design processes fail to include, consult with, and listen to the people we are actually designing for, we also fail to design effectively.
    – Lisa Herrod

    The source of this quote is http://scenariogirl.com/inclusive-design/the-social-model-of-disability. It has been broken for a while due to ISP issues. I keep referring to the link until it works or a new one replaces it.

    Image of man taking a photograph reflected on a metal surface – Slide 34

    In summary, think about how your work reflects back on you. The man in the photo sees his reflection on the shiny surface of a button on a lamp post in the city. Think back to the starting thought about quality – what quality will you see in your work?

    Official closing slide – Slide 35

    Thank you for listening! Questions?

    @kmdk / @stcaccess

    https://www.mardahl.dk

    http://about.me/kmdk

    Extra – Slide 36

    All of the following slides are extras that would have been used as I saw fit on the spot. They are “as is” for interpretation.

    Mobile – Slide 37

    User diversity – Slide 38

    Test with real people!

    Users are different. But are you aware of the variety? When you test your systems, test with real people who have real disabilities. Personas can be a substitute in some cases. Personas can help teach accessibility. Developers are more likely to respond if they can see how people can be affected by their inaccessible web pages.

    Demo of an accessible infographic and alt text – Slide 39

    I (heart) WebAIM.org

    (Slide 39 through 44 show screenshots that illustrate good use of alt text and an accessible infographic. It is meant for situations where there is no wifi.)

    Confession: I love WebAIM. They have so many resources I can learn from. Let’s start the discussion with an example from WebAIM: an infographic of web accessibility tips for designers (and developers). A pretty .png picture. Useless to someone with little or no vision.

    Slide 40

    The pretty picture is available on their site – ALONG with a text version…

    Slide 41

    The text version is the text that is in the image we first saw. All the text was pulled from the picture and put into this alternate form. At the top of the screen shown here is a link to an accessible version of the .png file…

    Slide 42

    Someone else – Chris Throup – made an accessible version of the picture. Looks the same.

    Slide 43

    But the code reveals how there is no image in what looked like an image on the previous slide. It’s just code – machine-readable code.

    Slide 44

    This slide shows Chris Thorup’s code with – at the bottom of the slide – a sample of the WebAIM code for the text version. The same message gets across, but in 2 different ways. The WebAIM sample showed icons echoing the original image. However, those icons use alt text to tell a person using a screen reader what that icon represents. All in all, a lovely real-life example of making something accessible to many different needs.

    Twitter+ Resources – Slide 45

    People are probably the best resources of all. This is the tip of the iceberg here. I could talk for hours about the people I think you should follow. It caused me pain to not include some people. Some may be at a far higher level of coding knowledge than you are comfortable with. Break out of your comfort zone! Or share these links with your favorite developers. They are people well worth following. Note that the last one also has a forum where you can ask all sorts of questions related to developing accessibly.

    Coding resources – Slide 46

    Great coding resources for anyone wanting to get down and get real dirty! The Mozilla ARIA resource is huge and growing. Start your ARIA explorations there.

    Postscript

    Special thanks to John Kearney and Neal Dench for helping me finish this blog post. October has been crazy busy for me so the posting process got a wee bit too delayed.

    Thanks to the people of the WebAIM discussion list – especially Birkir! – who have been an inspiration for other presentations that led up to this workshop.

    Thanks to TCUK (and dear David Farbey) for inviting me to be a keynote speaker. That led to me daring to give this workshop.

    Material in this workshop builds on material from past presentations I have given. There are some messages (for example, the one about alt text) that still bear repeating. As long as there are things out there that are broken – and shouldn’t be, these messages need to be repeated.

Published in Uncategorized

5 Comments

  2. Chris Throup
    Chris Throup 5 November 2012

    Hi, Karen.

    I wasn’t at the conference, but I enjoyed reading your notes. I came across this post after someone started tweeting me about the accessible infographic I put together over 6 months ago. It’s nice to know it has generated some interest and that other people do care 🙂

    All the best,
    Chris

  3. Karen Mardahl
    Karen Mardahl 6 November 2012

    I’m glad you enjoyed it, Chris. I think your infographic is a great teaching tool. I used it once before, too. It’s great for getting people to think differently about infographics – the same thing that you did.

  4. Chris Throup
    Chris Throup 7 November 2012

    I think infographics are great examples of objects on the web for which people don’t bother considering accessibility because they don’t think they can. It’s nice to know other people are talking about it too.

    Just to be clear, I didn’t create the original WebAIM infographic; I recreated it as accessible text and shared it back to WebAIM.

  5. Karen Mardahl
    Karen Mardahl 7 November 2012

    @Chris – I think it is clear that WebAIM made the infographic first, and you followed with your version. That’s also an example of how great the internet is – things evolve.

    I should perhaps have mentioned you more directly in this article: http://www.stc-access.org/2012/08/16/putting-accessibility-into-infographics/ Read the comments and see where they lead. It’s not going as far as you did, but it’s like Jared said to you at one point – some don’t have the knowledge or the time (to do a CSS version, e.g.), but they can at least make a kind of transcript. I think doing what you did is how a designer/developer can showcase their talent and get people out of the paper mindset while on the web.

Comments are closed.