Accessibility Camp Toronto 2015 Recap

This past Saturday marked the 5th edition of Accessibility Camp Toronto, a day dedicated to connecting people on digital accessibility solutions. I believe this was the third year I’ve made the drive down from Ottawa the event. As usual, the presentations and the people there delivered value in spades!

The event is big enough that it had multiple sessions going on at one time. I’m recap the best things I learned from the sessions I attended throughout the day.

Welcome

An introduction to what the day will be like. Not sometime I would typically recap, but one of the things that I love about a11yTO each year is the effort the organizers put into making sure that attendees with a variety of disabilities are able to participate in the day. If you’re mobility impaired, the venue itself is accessible – win! There’s CART services in every room, so each word spoken by the presenter is typed out and projected live.

Session #1: Introduction to Accessibility Mechanics with Leonie Watson

In a great start to the morning, Leonie Watson gave an introduction to the crowd about how web browsers handle accessibility. Her talk gave insight into the advantages of using the appropriate HTML markup when designing our web pages. Using the semantically neutral <div> and <span> elements to build a widget about Tequila (who says we can’t have a little fun on a Saturday) she showed how to mark up the elements with ARIA so that screen readers would correctly interpret her code. Much of what she did could have been replaced with a <button> element – which was really the point. The browser can handle a lot of things for us, make use of it!

My takeaways from her talk:

Do as little as possible. Write good quality HTML, you’ll be surprised how much the browser will take care of for you.
Web Browsers have a built-in Accessibility API. Like the DOM, it is a tree of the elements on the page. There’s a blog post from the Paciello Group, “The Browser Accessibility Tree” that explains it in detail.
HTML Accessibility API Mappings 1.0 (W3C Document) explains the relationship between HTML elements and the browser’s Accessibility API
There are many ARIA states and properties that can be set in your HTML code.
ARIA markup does not change the DOM, only the accessibility tree. It does not change the functionality or behaviour of HTML elements, but provides extra information to assistive technologies.
There’s a Visual ARIA Bookmarklet to help show you how ARIA is implemented on your web pages.
Tabindex=”0″ can be used to make a <div> or <span> accessible by keyboard navigation, placing the element in the default navigation order.

Session #2: Introduction to Screen Readers for developers with Terry Bray

During this presentation, Terry Bray showed a room of developers what it’s like to navigate web pages with a screen reader. Screen readers, like JAWS, NVDA or VoiceOver, read the contents of the page aloud to the user, while making extra information available for properly marked up pages (see my notes from Session 1 above!). He showed how simple changes can make the life of a screen reader user much easier.

I felt this was really an extension of the first session I attended, drilling home the importance of proper markup, and testing. (This is a repeating theme – I’m sure I’ll say it again before this post is done!)

In case you’re wondering – screen readers are not the only types of assistive technologies out there. I found a post from Microsoft talking about the types of assistive technology products (both input and output) that is worth a read if you’ve never had a chance to see these in person.

As an aside, a demo like this one is how I first got interested in web accessibility. I had developed a web site with the results of the first Public Service Employee Survey while on contract with the Government of Canada. I had the opportunity to have the site tested by two users with different disabilities, and was really disheartened to see how much effort it took for them to navigate and understand my work. There had to be a better way! Still to this day, watching a user with a disability navigate the web is the best reminder of why we need to take the time to do this right.

Lunch

Same as last year, catered by Caplansky’s Deli. If you’re in Toronto, check them out. They made sure that my stomach was as happy as my brain!

Session #3: Everything you need to know about JavaScript accessibility with Karl Groves

It’s always a pleasure to listen to Karl “The Viking” Groves speak. When it comes to writing accessible code, he knows his stuff!

In this session, Karl showed the audience how to build an accessible login modal dialog. It focused (pun intended) on making sure that when the login button was clicked, that in addition to displaying the modal dialog, the focus was put into that dialog. In addition, he covered important things to pay attention to, including:

Is the “X” in the corner of a modal dialog read as “X” by a screen reader, or as “Close Dialog” ?
If you press ESC (keyboard navigation) does the modal close?
When the modal closes, what object gets the next focus?

The code for this project can be found in his GitHub repository.

Takeaways:

I’d heard it before, but had forgotten the 4 principals of accessibility that spell POUR.
It’s easy to set focus on an element, yet often forgotten. Test, test, test!

Session #4: Accessibility Testing Tools with Luis Garcia

Ooh, new toys!

Luis Garcia, from Deque Systems, showed the audience a handful of really useful testing tools you can use when developing or auditing a website for accessibility. You can find the list of accessibility testing tools on his website.

My takeaways:

HTML CodeSniffer is a handy bookmarklet that tests the current web page against a selected accessibility standard. Really handy! In fact, I’ve already used it since coming home from Accessibility Camp.
Accessibility Developer Tools, from Google, is a Chrome Extension that adds lots of accessibility checks into the Inspector.
I’m really looking forward to using the Tenon.io API in an upcoming project to automatically test code for accessibility. (Combined with manual testing too, of course!)

Session #5: Usability Testing for Accessibility with Linn Vizard & Heather Moore

I love the idea of usability testing. UXCamp Ottawa (now CanUX) drilled this into my head over the past few years. Last year, Steve Krug, the author of Rocket Surgery Made Easy, performed a usability test live on stage with a random member of the audience. The point was to show how easy it was to perform one.

All this being said, I was really happy to find Linn Vizard and Heather Moore from Usability Matters discussing user testing, but with a spin on testing using participants who have disabilities. I hadn’t considered some of the adjustments that would need to be made to a typical usability test.

My takeaways:

Do your own testing first… don’t waste the participant’s time. Coolest thing in this regard, did you know that Adobe Photoshop has Colour Blindness Filters ?
If you’re going to record users doing their usability test, make sure they sign a A/V release waiver. This goes for all user tests, not just accessibility ones. It’s just something I hadn’t considered.
Make sure all that materials required for the test are also accessible. The example given was that if the user needed to enter a credit card number into a form, make sure that the paper with the credit card number had large print, or a braille card was available.
There are many different types of technologies used by users with disabilities. Rather than asking them to come to your office, or some other facility, to participate in the test, it could be a huge time saver to go visit the user at their location. This does take more of your time though, make sure you account for that.
Make sure to document exactly what technologies the participant was using. This will be important when your development team is trying to replicate a problem discovered during the test.
Advanced screen reader users can read at up to 900 – 1200 words a minute. WOW.

Closing Remarks

Organizing committee member Billy “The Lumberjack” Gregory made a big announcement. Next year, in addition to Accessibility Camp Toronto, there will be an Accessibility Conference Toronto! No details available yet, but I’d say it’s safe to assume this will be a multi-day event that builds on the momentum and greatness that the camps have been over the past five years. I can’t wait to see what they put together.

They made it clear though, the camp will continue. The new conference will be in addition to the annual camp.

After-Party

No Accessibility Camp is complete without a great after-party. As usual, this year delivered. It didn’t hurt that the Blue Jays game was on at the same time. Made for a great party atmosphere while catching up with old friends and making new ones.

Conclusion?

So you haven’t been to an Accessibility Camp yet? What are you waiting for? Hope to see you at one next year!