Adina Halter is Sr. Product Manager and Chief Technologist for Accessibility at Comcast where she ensures the accessibility of all Comcast products from web, to mobile apps, set top box applications, smart-home applications and other internet-of-things offerings. She is a member of the W3C’s Web Accessibility Initiative Education and Outreach working group and tweets, instructs and speaks on coding, accessibility and women-in-tech issues.
When did you first get started in accessibility?
I joined Comcast NBCUniversal as a web development architect 5 years ago. Soon after starting I was given the task of making our self-service product accessible for keyboard devices and screen readers. I had 3 months in which to do it. Talk about trial by fire. What I realized through this exercise (and, yes, we did make our deadline) was that semantic, elegant markup, CSS and JavaScript was a key player in ensuring a product was accessible. Since I had a passion for lean, elegant code, the synergy between this and accessibility ignited a passion for me toward accessibility.
I’m also a problem-solver by nature. As many of our products use complex design and development patterns, I found it thrilling and empowering for all involved to be able to brainstorm and whiteboard an accessible solution with a product team. Again, the leaner and more elegant the solution, the better. That really jazzes me.
While I was still in my web development architect role I began to flesh out accessibility standards and accessible code patterns for our engineers to follow. This meant our product features were launching accessibly. I created an accessibility training program for developers and QA testers on our team. Within a year and a half I was approached by Tom Wlodkowski to consider moving to Comcast’s accessibility team to continue my work in this area while reaching a wider product design and development audience.
You have worked for the W3C’s WAI Education and Outreach Working Group. How did that experience affect your approach to accessibility?
The first work I did as a member of the WAI Education and Outreach Working Group was to help develop the Perspectives Videos. I have a background in Video Production and was able to bring that expertise to the team as we interviewed production companies and then worked with our chosen production company on scripts, choosing voice-over talent and post-production.
Working on these videos gave me a glimpse into the myriad ways those with disabilities can be either hindered or helped by products around them, depending on how these products were designed and developed. As my friend Sam Joehl said, “Closing your eyes doesn’t make you blind.” These perspectives took my knowledge from theory to understanding.
Working on these videos was also a catalyst in my recognition of myself as a neurodiverse individual. Prior to this, it never dawned on me to identify as a person with a disability. I felt my neurodiversity was something I just lived with. I learned that I, too, responded better to a product with a simplified user experience. I was then able to bring this newfound understanding to the table when our working group began the new WAI design initiative.
On your GitHub page, you have an accessible autocomplete tool. Can you tell us more about that project?
The accessible autocomplete tool is a work in progress. I wanted something that was intuitive and could be used in either web or mobile environments. I relied on our team members who use JAWS regularly to give me feedback. I also relied on the International Association of Accessibility Professionals members to weigh in.
I love the idea of using the robustness of ARIA to create solutions. With ARIA you can really create some elegant widgets with lean markup and code. Of course success relies on the browser and screen-reader support given to these robust ARIA attributes.
I wanted to experiment with mixing an input element with div options. I also wanted to experiment with aria-activedescendant and aria-selected. I utilized a roving ID on elements with role=”option” to trigger aria-activedescendant announcement. I added hints using both aria-describedby and an aria-live region.
This was built well before JAWS 2018 so I didn’t worry about IE Edge support. Since JAWS 2018 was launched to support Edge, I have noticed lots of issues due to spotty support with aria-expanded, aria-selected, and aria-activedescendant. There is a lot of chatter about these issues, some pointing to JAWS 2018 and some pointing to Edge support.
I’ll probably wait until the dust settles before revisiting the autocomplete tool.
Tell us about your work at Comcast. What are some projects you are currently working on?
My main job is to work with the developers on different product teams to ensure they develop with accessibility in mind and to help them discover solutions for complex interfaces and coding patterns. I write and maintain standards and coding solutions for web, mobile and other technologies. The rise of single-page applications, the shadow-DOM and custom HTML elements have added a new layer of complexity to accessible solutions. I love that kind of challenge.
I am also continuing my work on accessible code patterns. I am currently working on a pure CSS data table solution for graphing where the table IS the graph.
What is a major accessibility barrier that you would like to see solved?
I would like to create design and development standards and solutions to address the needs of people with multiple disabilities and variances in disabilities. Someone who is blind or who has a physical disability may engage with our products in a very different way than someone who is both blind AND has a physical disability. Someone who has low vision interacts with a website or mobile app differently than someone who is completely blind. We need to consider more robust personas and really think outside the box when designing and developing for people with multiple and/or variant disabilities.
I’ve seen you speak a few times and it’s always great to hear your insights, Adina! Thank you for doing the work that you do!