Why I'm running for TAG
(If you want to know what this TAG business is, check out Brian's Primer for Busy People. Alex's post supporting my nomination has a bit more history as well.)
Early in 2011, right as I was about to begin work on the Chrome team in Sydney, I happened to catch a talk by Jason White on his experience using Linux, and the web, via a screen reader.
While not quite my first brush1 with the experiences of assistive technology users, it really made something click for me. I had actually been ready to leave the tech industry altogether (and had even been accepted for a part-time degree in a different field, but that’s another story), but Jason’s description of using a web browser via a screen reader, and how ARIA worked, persuaded me to give it another try. I saw a reason to be optimistic about technology, and an opportunity to work with people with disabilities on making the web a tool for greater empowerment and freedom.
Chrome Accessibility
So I came in, more or less cold, to accessibility 8 years ago. I was fortunate enough in the beginning to be introduced to Dominic Mazzoni (the creator of Audacity!), who had already done a bunch of heavy lifting in the Chromium codebase to integrate what back then was WebKit’s accessibility implementation. Dominic really impressed his philosophy of accessibility on me - fundamentally pragmatic, compassionate to both developers and users with accessibility needs, and always future-facing.
As the Chrome and Chrome OS accessibility team has grown, Dominic has had a huge hand in ensuring that our team represents a large slice of our users. We were joined very early on by David Tseng, lead developer of the current version of ChromeVox, and now tech lead for our Chrome OS accessibility efforts.
Our full team now includes senior developers who use screen readers, users of magnification and high contrast, and people who strongly prefer to use alternatives to pointer-based input, alongside teammates with no specific accessibility needs but a strong belief in the team’s mission. I learn on a daily basis from working with such a diverse and talented group of people.
Learning the ropes
One of my earliest projects was the Accessibility Developer Tools extension and library, which aimed to integrate accessibility checking and debugging into Chrome DevTools. This forced me to really dive into WCAG 2.0 and begin understanding the broad and occasionally somewhat patchy terrain that is accessibility on the web. (I have, in fact, given a whole talk just on contrast ratios, colour representations and the “suggested colour” feature in Accessibility Developer Tools.)
Around the same time, the Web Components project was really getting underway, and I was able to work with the Polymer team and help them ensure that their original suite of components met a high bar for accessibility. This work showed me first hand some of the challenges facing web authors, and web component authors in particular.
In the world beyond Google, I have been fortunate to learn from the many accessibility experts who contribute to web standards, and others who share their knowledge via talks and articles. I am a particular fan of Léonie Watson, who has been a long time contributor to web standards and consistently produces top notch talks on cutting edge accessibility topics. James Craig stands out as another abled ally whose pragmatism and solutions focus has helped form my approach to accessibility.
Developer experience and potholes
I consider my overarching mission to be improving the developer experience of web accessibility - tying together tools, APIs and education to help bring truth to the idea that the web is "accessible by default". As most accessibility professionals know, "accessibility" is something of an unreachable, moving target - nothing is ever "perfectly accessible". As user experience and front-end development patterns continue to evolve, we need to evolve accessibility techniques alongside them. At the same time, research and development in the accessibility sphere drive the creation of new accessibility best practices.
In the past few years, I've become increasingly involved in Web standards. I am hopeful that it can be an effective lever to "raise the floor" for web accessibility.
In my TAG election statement, I wrote about my belief that "most web developers would like to create accessible experiences, but that unfortunately the easiest way to write code can result in an inaccessible experience". I have seen this over and over with things like flex order, floats, reset stylesheets disabling the focus outline, requiring redundant event listeners for click and keypress, hand-rolled modal UI, Shadow DOM breaking label and IDREF association, tabindex woes, display: contents, etc., etc., etc. Educating about accessibility can sometimes feel like handing out roadmaps with potholes marked on them, and instructions on how to build small bridges from scratch with foraged items.
I think we can do so much better. I think accessibility professionals would love to stop helping people go around potholes, and start helping people innovate on truly delightful, inclusive user experiences.
Doing better
Within the projects I'm working on, the Accessibility Object Model project aims to mend some accessibility potholes in the Web Components story, and give developers more expressive APIs to declare the semantics of their content. inert aims to give developers simpler tools to manage focus. focus-visible is designed to create incentives for designers to embrace bold, visible focus styles, rather than hide them or minimise them.
But I believe we also need to avoid creating new potholes, and this is why I hope to be able to work on the TAG. My experience as both a browser developer and accessibility advocate gives me a rare perspective that I would like to bring to nascent Web standards, and help standards engineers understand accessibility considerations in their own work.
The future is accessible. Inclusion of people with disabilities benefits everybody. The more we can improve the basic infrastructure of the web, the more we can drive participation of people with disabilities in web standards, and create a virtuous circle for accessibility and usability. I hope to have the opportunity to help move standards in that direction.
-
That would be a chat over coffee in 2001 (!), with a reality TV afficionado who was blind. She couldn’t navigate the online voting form for Big Brother Australia because the buttons at the end of the form weren’t labelled correctly. I still use this example for why accessible names are important to this day. ↩
Oldest comments (5)
Welcome to the community, Alice, and best of luck!
I find writing accessible first html is better planned and I have really enjoyed working in this way. I prescribed to ecss instead of BEM which encourages UI state to be styled via aria instead of extra css classes.
Loved this article, good luck Alice!
I was very excited when I heard the news about you've joined the group of awesome people. : )
Congratulations!! I'm sure that you'll make the web a better place for everyone.
Thank you Jihye! I'm looking forward to working with you again :)