GAAD 2017: I wish I’d known…

I wish I’d had somewhere like the A11y Slackers channel when I was starting out. It’s a free and open place to ask accessibility related questions, and get answers from a lot of smart people.

It wasn’t “things I wish I’d known” but “people I’d wish I’d known”, specifically people like those I met at my very first disability related conference back in 1988 who were using assistive technology (lots of augmentative communication devices) that inspired me to follow the path i’ve been on now for almost 30 years, and to also not listen to others who often said ‘that can’t be done’.

I wish I had known that using as much of the built-in settings in applications like Word and InDesign would have made fixing a PDF 10 times easier. If those programs are exporting to PDF, obviously it’s using whatever setting the software maker uses, but it took me a while to figure that part out.

One thing I wish I’d gotten my head around sooner was how important connecting up the dots in interfaces is for accessibility. It’s not just about making discrete elements have accessible labels and legible fonts; it’s also about the journeys users take through pages, by keyboard, screen reader, touch exploration, or visual affordance. Structural order and relationships are so important.

I wish I had started out thinking about web accessibility in terms of actually supporting people to use the web, rather than merely ensuring conformance to a set of guidelines. Once you go beyond the guidelines, and focus on providing a positive user experience for people of all abilities and disabilities, web accessibility stops being an onerous, rule-bound task and becomes an interesting and creative challenge.

I wish I had known about change management as a tool for advancing accessibility in a profound, systemic way. I didn’t realize how much redirection is needed for accessibility to become a standard in the technology field, and a requirement for being a technology professional. If I had know, I would have learned more about human factors and change and had more change management tools in my toolkit, such as the guiding principles and practices of liminal thinking, methods of design thinking, and the gentle art of humble inquiry, to help people, teams, and organizations transition to prioritizing accessibility in their technology projects.

I wish I had appreciated that the entry point for web accessibility isn’t necessarily about becoming an expert screen reader user, or knowing the WAI-ARIA specification inside out, but (for me) simply a willingness to produce and promote clean, standardised HTML, combined with a strong and unwavering empathy for people who may face barriers to your product when this is not the case. As with all web development, learning about accessibility is achieved through learning by doing, for example by (re)building or following examples such as those created by Heydon Pickering and Hans Hillen. You can use those examples to understand how complex widgets can be coded accessibility, and to get familiar with assistive technologies, but bear in mind it is absolutely fine to take baby steps – once you gain this grounding, you can build your knowledge further through reading the WAI-ARIA specification in more detail, and becoming a more experienced and confident accessibility practitioner.

When I was starting out, I wish I’d known that while following accessibility standards and guidelines is vital, it’s not the only thing you need to do to create great user experiences for people with disabilities. Involving people with disabilities early and throughout the design process is a valuable way to help you better understand a problem and design better solutions to the problem. One book I wish I’d had from the beginning is Graham Pullin’s “Design meets Disability”, which beautifully demonstrates how thinking more about disability can influence and inspire great design. I’d recommend it as essential reading for anyone setting out to work in accessibility and inclusive design.

I wish I’d spent more time using AT products in my daily interactions, in order to get a better understanding of the issues faced each day by the people whose user experience we try to improve.

When I was first starting out playing in accessibility in the late 90s / early oughts, I wish I had known how easy it is to access local organizations that offer services for constituents with disabilities. Getting real users with real experience with assistive technology to walk you through their tools and your sites was an experience I wish not only I had sooner, but I wish every developer and instructor had today.

I wish I knew just how much of a community there was around accessibility and how willing people are to share expertise, particularly if it results in a patch getting submitted to their code – picking up accessibility bugs on established projects and learning through peer review from more experienced people is a great way to pick stuff up.

I think the most important piece of advice I could share with anyone starting out (and I’m still just starting out myself), is to become accustomed with the tools of web accessibility. It could be a screen reader that may already be built into your computer or device. It could be TPGi’s Colour Contrast Analyser, which is free and available for download. It could be ZoomText. There are so many options out there, and I wouldn’t suggest one over the other. You will find out which one works best for you, and even that will change over time. It is the tools that are the conduit to understanding how others navigate the web and ultimately the world around us. Through that understanding, you develop empathy for others, and as your scope of web accessibility broadens, so will your insight and passion. There is nothing sexier in this world than understanding and compassion for your fellow human beings.

I wish I knew about ARIA and its Authoring Practices when I started out in accessibility. Both documents have helped me tremendously to get a deeper understanding of how everything works behind the scenes and what it means for a website to be accessible. Perhaps more importantly, they have helped me to write better, more stable, and all-around more inclusive websites and web apps.

The thing that I wish I had when I got started in accessibility is a community. When I first got started in accessibility in 2001, all I had was Section 508, Bobby reports and what I could find on Yahoo! and Altavista to guide me. It was bleak times and we used a lot of trial and error to make things accessible with the handful of users we had access too.

Accessible Web Components using Polymer by Alice Boxhall, 2014

This was one of the first talks I heard about Web Components and accessibility. It describes the technologies that underpin Web Components, and how you can use the Polymer library to make accessible components. Web Components (and Custom Elements in particular) have changed since 2014, but this remains an area of exciting possibilities – both for development and for accessibility.

Accessibility by Design by Laura Kalbag, 2015.

Inclusion starts with design. I love how Laura gives a designer perspective not on what is just ‘pretty’, but what is pretty effective, in other words inclusive.

Uncharted 4: A New Adventure in Video Game Accessibility by Sony Interactive Entertainment, 2016

The first of two talks on game accessibility in 2016, this was a great introduction to the accessibility features in games like Uncharted 4, and the decision making process for including control and content alternatives.

Changing Tides: 2015’s Games Industry Accessibility Advancements by Ian Hamilton, 2016

Ian Hamilton is a great source of game accessibility knowledge, something I know pitifully little about, It’s great to have folks like him pushing a11y in games forward.