Meet Graeme Coleman. Single-handedly propping up the Scottish arm of TetraLogical, Graeme has been tirelessly working towards better accessibility with us since the very beginning.
Graeme's journey to digital accessibility has been an unusual one. As a youngster, he was hugely into new technologies but felt that enthusiasm wane and ended up studying for a degree in accountancy. Several years of bookkeeping and accounting later, Graeme saw the light, and his interest in computing was reignited.
He returned to university to do a Masters degree in Applied Computing at the University of Dundee and remained in the department as a PhD student/research assistant. More details of his qualifications can be found on his website, Graeme Coleman.
It was during this time that web accessibility was gaining momentum, the Web Content Accessibility Guidelines (WCAG) 1.0 had just been released, and Graeme found he was levitating towards the field. He began working as an accessibility consultant for the Digital Media Access Group (DMAG) who were based at the University of Dundee. Now, after a solid 20 years in the field, Graeme reckons it’s probably the career for him.
Graeme’s main interest at TetraLogical relates to native mobile app accessibility and, in particular, some of the nuances that need to be considered when assessing native mobile apps – as opposed to websites and web applications – against WCAG. For example, in Android accessibility: roles and Talkback, Graeme shows how element roles within native Android apps aren’t always announced.
Graeme has also acted as project lead in working with a number of large clients during the early stages of a product’s development to ensure that the product not only conforms to WCAG, but also provides a positive user experience for everyone who uses it.
Affectionately known as the King of VPATs (Voluntary Product Accessibility Template) in the team, Graeme has unparalleled knowledge and experience on Accessibility Conformance Reports (ACRs) in his role as Principal Accessibility Specialist. In his post introduction to Accessibility Conformance Reports (ACRs) Graeme explains when ACRs are needed and how they are created.
He works across assessments, consultancy, larger embedded accessibility projects, training, and service development.
In all honesty, we’re yet to find something Graeme can’t do.
Although the rest of the team think he’s rather talented, Graeme is insistent that he is an (extremely) amateur musician; the emphasis here being his own.
He’s an avid synth collector, owning several professional synthesizers and keyboards from the 1980s and 1990s, so you’ll occasionally find him in out-of-the-way second hand shops and outbidding you on eBay. He also runs his own YouTube channel featuring remixes of contemporary songs in a 1980s style. Particular notoriety has come to Graeme through his politician resignation series, started by this viral tweet of David Cameron leaving office.
Graeme is also a keen language learner who speaks rudimentary Danish and (extremely) rudimentary Italian. He has travelled eastern and Central Europe extensively and keeps records of his adventures on his Flickr account, which is beautifully organised in typical Graeme style.
What's the one thing you wish you'd known when you started learning about accessibility?
Not to be overwhelmed with standards documentation. When I was first introduced to the field, and even for a year or so afterwards, I would try to sit down and read all the WCAG 1.0 (followed by WCAG 2.0 and WCAG 2.1) standard document, as well as other specification documents such as WAI-ARIA, and just feel like there was too much to learn.
At some stages, I felt like giving up. What I subsequently discovered is that, while they are of course important, these documents are essentially references that one should dip in and out of, rather than something one needs to keep in one's head at all times.
For a developer new to accessibility, or for someone who is interested in the relationship between technology and accessibility, there are lots of high level resources online that you should read through first - and lots of people within the community who are approachable and eager to help out when they can!
What's your top accessibility tip?
As I mostly communicate with development teams, I would definitely recommend that you test, test, and test again during development, not at the end! This is particularly important when creating complex custom widgets. Is it keyboard accessible? Is it labelled correctly? Does it have the correct role? Can it be operated when a screen reader is running (including on touchscreen devices)?
Doing all of this step-by-step as you build the widget will save a lot of heartache at the end, trust me!
What's your top accessibility resource?
Oh, there are so many! WebAIM is a great one-shop stop for high level articles on accessibility, particularly if you are new to the field.
The MDN Web Docs accessibility documentation includes numerous resources on how to actually make web content accessible from a technical perspective, while blog posts from folks such as Adrian Roselli and Scott O'Hara are great for keeping up to date with the latest techniques and for explaining unforeseen or unusual problems that often aren't documented in the official documentation.
More from Graeme
We like to listen. If you have a project, product, problem, or idea that you want to discuss, get in touch!