axe-con 2025: day two

Day two is here! I think we're already feeling a little conference fatigue but we'll make it through!

All aboard! A trip through Europe’s 7½ accessibility standards

Speakers:
Wilco Fiers, Senior Accessibility Engineer, Deque Systems
Shadi Abou-Zahra, Principal Accessibility Standards and Policy Manager, Amazon

Summary/Insights: Ashley Helminiak

Wilco and Shadi certainly leaned into their theme, complete with conductor hats and a train whistle! It also jumped off of the morning keynote nicely. The EAA doesn't actually refer to WCAG as a benchmark for success, but has its own list of requirements. Is there overlap? yes. But can you be compliant under one but not the other? Also yes. Woot woot. But hey, at least WCAG to EAA guidance exists to help us out.

Here are some of the EAA requirements beyond WCAG:

• Provide two-way real-time text with voice communication.
• Authoring tools enable and guide creating conforming content. The Authoring Tool Accessibility Guidelines (ATAG) will likely be a good source here.
• Biometrics shall not rely on only one biological characteristic.

I do like the fact that the EAA requirements are a little more human friendly to understand than WCAG. Wilco and Shadi also did a good job illustrating the intersection between WCAG and the EAA (basically A and AA level WCAG applies to EN 301 549, while AAA conformance is only on the WCAG side, and standards are more widely applied to products and services on the EAA side).

This is however, a wake-up call to organizations that are still snoozing on the EAA. Any companies that do online business in the European Union would should do the following before June 28:

• Have an accessibility statement on their website that shows how they comply with the EAA. Level Access has a decent one-sheet that touches on the topic. An accessibility statement should minimally include:
  • Information on product/service functionality.
  • The standards the website aspires to (this should be WCAG 2.2 AA).
  • Method(s) to contact someone to report an accessibility issue.
• Conduct testing and remediation to ensure their website is WCAG 2.2 AA compliant.
• Put a plan or mechanism in place to handle delivering timely text alternatives for audio and video (to start June 28th at the latest).
• Put a plan or mechanism in place to evaluate and remediate PDFs and other documents published to the web (to start June 28th at the latest).

When your role has you spinning plates and all you can hear is the sounds of smashing crockery

Speaker: Neil Milliken, Global Head of Accessibility, Atos

Summary/Insights: Ashley Helminiak

I liked Neil, he was very matter of fact and honest as he shared some of his war stories about building accessibility within his organization. Along with the fact that he had to whip up his presentation after he was chosen to speak! As an individual with ADHD and dyslexia, he used his neurodivergent lived experience to help support and drive change. They encountered several problems and setbacks (in other words, smashed crockery) when building accessibility within their organization. He also is of a mindset that we should work for results, not perfection. We can build off of imperfect results, but withholding progress while we seek perfection does an active disservice to our users.

I thought his points about burnout in the accessibility space were very valid. Especially without organizational buy-in, we can take too much burden on ourselves to try to fix everything. But if we work to compromise and make reasonable incremental progress, we should teach ourselves to take that as a win and keep going at a more reasonable pace rather than lamenting that we haven't yet achieved the larger goals.

One concept that Neil brought up was "useful failures." In other words, let it break. Because sometimes letting it break is the only way to get the support that's needed to make true progress with accessibility. Well said!

Speed without Sacrifice: Building an Accessibility-First Culture in Agile Teams

Speakers:
John Sweet, VP, Accessibility and Technology Compliance, Paramount Streaming
Andrew Walker, Senior Technical Program Manager - Accessibility Compliance, Paramount Streaming

Summary/Insights: Ashley Helminiak

I wanted to attend this talk because we work with a few different clients where we have a quasi-agile way of working. They addressed some misconceptions right off the bat, such as the idea that accessibility is "slow," usually due to ignorance, fear of friction, or lack of experience. However, it will slow things down if you don't plan for it, so that becomes important when incorporating it into agile development. Here are some things they suggest to pave the way to success:

• Deliver accessibility requirements in a language each team (member) can understand.
• Consider it a crucial component throughout the assembly line.
• Deliver requirements in advance of implementation.
• Don't overwhelm the team with the sum of issues.
• Plan upcoming accessibility development in big picture (quarterly) meetings.

Overall, I found their initiatives impressive, from having dedicated team members to each product area, to hiring testers to create use cases. The envy of this agency lady for corporations with big pockets is coming out. They did however, have a fairly small team within a large organization, and strived to make knowledge available to everyone, regardless of niche or skillset. Now to figure out ways to do that in our agency setting!

Navigating the European Accessibility Act (EAA) for Mobile Applications

Speaker: Rachael Yomtoob, Product Owner - axe DevTools Mobile, Deque Systems, Inc.

Summary/Insights: Ashley Helminiak

Rachael gave a nice overview on the differences between mobile websites and mobile applications and how they're really built with different technology, with apps relying heavily on native views. She pointed out that in addition to WCAG, mobile apps have some guidelines they can follow, such as Apple's Human Interface Guidelines, and the Android Developer Accessibility Guide, though they don't carry the same weight in the courtroom as WCAG. She also brought up other initiatives to apply WCAG to mobile apps, like the Mobile Accessibility Task Force, Appt Foundation, and MCAG from Evinced.

Much of the rest of her talk went into detail about how WCAG or WCAG-style requirements to comply with the EAA, which was mostly nothing new to me. One of my takeaways from this talk was (yet again) the reminder that the EU is ahead of the US when it comes to accessibility and adopting the latest standards, since the document from the Mobile Accessibility Task Force is expected to be used as a standards guide for the next iteration of the EAA. We're trying to catch up, I promise!

Testing Products for Accessibility: Why Manual and Automated Testing Go Hand-in-Hand

Speaker: John Caplinger, QA Analyst, Livefront

Summary/Insights: Ashley Helminiak

I found it refreshing to hear from someone with a dedicated QA role. He helped to form the guidelines for his organization, and has a philosophy that I share, to teach other people to recognize inaccessibility, so they can start to do something about it. His overall point was that there are strengths and weaknesses in both automated and manual testing, and how you should choose the most appropriate solution depending on the need and context. Each type of testing has different strengths in categories like speed & efficiency, consistency, scalability, basic issue detection, and cost. They also had weaknesses in areas of context understanding, UX evaluation, custom component testing, dynamic content updates, understanding if guidelines, and cognitive and visual issues.

John found that while he was able to find more user experience issues, automated testing found more technical errors. While there was overlap, the coverage of error discovery was larger when using both methods. Also, on a presentation note, I really liked how his slides faded out content that wasn't what he was talking about so the topic he was talking about came forward for better focus and less overwhelm. Nice design choice!

Burnout, Bullsh*t, and Broken Systems: Surviving Digital Accessibility in the Trenches (*Content Warning)

Speaker: Kevin Andrews, EIT Accessibility Coordinator, Georgetown University

Summary/Insights: Ashley Helminiak

I feel as though I have a kindred spirit on my soapbox. Accessibility is an uphill battle, and it can be extremely discouraging when you don't get the support you need or the buy-in you want to make real change. I myself have felt rather helpless at times, seeing glaring accessibility barriers on sites but not having the budget to fix it. Kevin had some great tips on helping to prevent burnout and maintain some semblance of sanity as we continue fight:

• Set clear boundaries. Don't train your workplace that you will be a "unicorn" without a unicorn's salary, or a proper work/life balance.
• Practice self-care. You can't do a good job if you aren't taking care of your physical and mental health. If you're worn too thin and forgetting to take care of yourself, nobody wins.
• Build a strong support network. For me, I have some people in the industry that I touch base with, as well as a strong team of coworkers that are accessibility minded that help get our internal initiatives off the ground and unify our best practices across projects.
• Celebrate small wins and progress. I would love to get better at this one. Sometimes I get dispirited even when improvements launch, seeing what all is left. But small wins represent products being more usable, clients investing in accessibility and quality, and more. Plus, who doesn't like a good party?

Kevin also discussed thriving, not just surviving. Though it's difficult, we need to try to maintain a balance and be intentional as we move forward. Every battle won, however small, is still won. And, often, it's cumulative, not just an improvement on a website, but a new lesson learned for a developer on the team, and new consideration that clients will keep as they seek new features and upgrades. Not such a small win after all!

---

But… Why?

Speaker: Melanie Sumner, Product Accessibility Lead, HashiCorp 

Summary/Insights: Haley Troyer

In her talk, Melanie Sumner talks about common accessibility mistakes that she sees across standard web components, like cards and forms. She says that, even if you’re using a design system that is accessible, it’s still possible to make accessibility errors.

The most interesting part of the talk for me was Melanie’s coverage of The Accessible Name and Description Computation (or ACCname and ACCdesc). This refers to a specification that instructs different browsers on how to calculate accessible names and descriptions based on the markup. It was helpful for me to see the order in which browsers will look for names and descriptions of web elements.

For accessible names, the browser will follow this order when determining what the name of an element should be:

• Aria-labelledby (references a text element that already exists on the page)
• Aria-label (good for when there isn’t a text element on the page to reference, like an icon button)
• Aria-describedby
• Semantic content (button text, label, legend, etc.)
• Title or placeholder (this is a last resort!)

Descriptions follow a similar pattern:

• Aria-describedby (references a text element that exists on the page)
• Aria-description (when there isn’t a text element on the page to reference)
• Elements eligible for description calculation and not already used for accessible name computation (i.e. table captions, summary elements, etc.)
• Title attribute (again, a last resort!)

There were some technical difficulties in the middle of the stream, but I’ll be sure to watch the replay to see what I missed!

Designing for Neurodiversity

Speaker: Craig Abbott, Principal Accessibility Consultant, TetraLogical

Summary/Insights: Haley Troyer

Neurodiversity is an umbrella term that includes anyone who processes information differently than what is considered “typical.” Examples of neurodiversity include ADHD, autism, bipolar disorder, dyslexia, and many more.

Craig Abbott spent the bulk of his talk going over the Cognitive Accessibility Guidelines (CogA) by W3C, which is a newer set of guidelines that attempts to bridge the cap between WCAG 2.2 (which doesn’t provide much information about supporting users with cognitive disabilities) and WCAG 3 (which is still a ways away). 

9 Principles of CogA

1. Help users understand what things are and how to use them. (examples: user universally recognized icons, structured headings, and only use color as an enhancement, not for communication)
2. Help users find what they need (examples: including a skip link, providing a sitemap, and narrowly scoping tasks)
3. Use clear and understandable content (examples: using plain language, legible fonts, and sufficient color contrast)
4. Help users avoid mistakes and identify how to correct them (examples: helpful error messages with instructions, allowing people to go back, showing examples)
5. Help users focus (examples: avoid interrupting tasks with popups, avoid autoplaying videos, and provide information up front to help users with a task)
6. Ensure processes do not rely on memory (examples: keep information visible for reference, don’t disable copy/paste functionality, and avoid hiding important information)
7. Provide methods of support (examples: contextual support, multiple support channels, and links to documentation for self-serving)
8. Support adaptation and personalization (examples: support for assistive technology, dark mode, zoom, screen sizes, and reduced motion)
9. Test with real users

Resources

• Neurodiversity Design System
• Inclusive Design Principles
• Microsoft Inclusive Design
• Adobe Inclusive Design

From AI Chats to Beyond: Building Our Accessibility Research Program

Speakers: 
Feriyal Hallajarani, Accessibility Lead, Thomson Reuters
Zenab Khan, Accessibility Consultant, Thomson Reuters

Summary/Insights: Haley Troyer

In this talk, Reriyal Hallajarani and Zenab Khan talk about the process they developed to improve their research processes to be more inclusive. They created prototypes for an AI chat feature for their company, Thomson Reuters, which provides tax compliance and accounting information, software, and services to professionals.

They focused on developing a panel of real users. This was a big challenge for them because their users needed to be tax or legal professionals that had a disability, and they wanted to include diverse experiences. This ruled out the possibility of using a third-party research recruitment service, so they handled recruitment internally. They quickly realized that many forms and screeners that they were already using were not accessible. They also realized that researchers weren’t familiar with assistive technologies or confident in leading sessions with disabled users.

These insights led them to create accessible screeners and other recruitment communications so they could more easily gather and accommodate users for their studies. They also developed training guides and processes for their interviewers so they could lead sessions confidently and respectfully (accessibility experts co-facilitated sessions in order to provide tech support).

Over time, they standardized their research processes, fine tuned their panel of users, and were able to start scaling their research system for larger scale tests. What they learned was that accessibility doesn’t need to be perfect at first. You can start with what’s feasible and iterate over time. Collaboration is key!

Panel: Digital Accessibility in Higher Education

Speakers: 
Mark Nichols, Senior Director of Universal Design and Accessible Technologies, Virginia Tech University
Eudora Struble, Director of Technology Accessibility, Wake Forest University
Al Nemec, Digital Accessibility Program Manager, University of Wisconsin-Madison 

Summary/Insights: Haley Troyer

The main topic was about the changes to Title II and Section 504, mainly the adoption of WCAG 2.1 Level AA as the technical standard of accessibility for higher education. Essentially, all content and systems used in higher education entities serving 50,000 or more people need to conform, and they have until April 2026 to do so (otherwise they’ll face legal action and fines). This includes anything from PDFs and images, to university intranets and content delivery systems. 

Despite what’s happening in the current political landscape, everyone on the panel agreed that, since the ADA is still federal law, there has been no slow-down on their efforts to comply with the Title II guidelines.

This is a daunting task for universities. The topic of accessibility overlays came up, but the panel unanimously agreed that overlays should be avoided. Not only can they break existing accessible features, but it can also prevent real action from being taken to actually make content accessible at its core. See the overlay fact sheet for more information on accessibility overlays.

Members of the panel discussed actions they’re taking to meet the April 2026 deadline:

• Statewide contracts - lowering fees for captioning and transcription services on multimedia content
• Add language to contracts that holds vendors accountable for making their systems accessible and putting pressure on them to do so (i.e. research journal archives)
• Find the “low-hanging fruit” that can be solved quickly and have a big impact, then move on to more complex initiatives
• Educating faculty on how to make their content accessible (complex diagrams, tables, etc.) and providing examples/frameworks
• Training employees on accessibility by supporting them through certification exams (CPACC)
• Getting students interested via events/challenges

I especially enjoyed hearing about the creative ways that universities are getting people involved to help this great effort!

Centering Neurodiversity for Better Product Experience

Speaker: Laurel Francoise, Staff UX Designer, Adobe

Summary/Insights: Haley Troyer

Have you ever forgotten where you placed your keys? This simple question opened Laurel Francoise’s whirlwind talk where she shared tons of helpful information about neurodivergence and usability. She argues that we all enter and exit disability throughout our lives. For example, if we’re stressed, sick, or haven’t slept well, our working memory can suffer, making it difficult to remember where you last saw your keys. She shared many wonderful ideas, so I’ll summarize those that I found most intriguing.

Workflow Analysis

Laurel shared an example of a complex workflow that had 71 steps across 7 browser tabs (holy smokes!) By analyzing the flow and cutting out inefficiencies, her team reduced the workflow to 32 steps and 1 browser tab. Obviously, this resulted in a much clearer experience. Here’s the process she shared:

1. Choose a specific task (the more complex, the better!)
2. Build the complete workflow, including all screens that users will see
3. Identify steps where the workflow branches
4. Notate transitions between different tabs/windows
5. Notate places where steps are repeated, screens are refreshed, new tabs are opened, and other inefficiencies
6. Calculate the amount of steps that could be saved if these issues were corrected

Neuroinclusion Principles

• Offer a single path to complete a task: User linear workflow paths and minimize branching workflows where users can get lost.
• Notify of transition changes between containers: Prime users before context switches and give them agency to decide when to make the switch.
• Promote transparent content layout: Avoid hiding relevant content or dispersing it across multiple containers.
• Leverage AI voice & tone to encourage users: Frame messages in a way that encourages them and reduces their fear of failure.
• Use inline editing options: Avoid placing editing tools across multiple containers to minimize context switching.
• Optimize user cognition with dynamic containers: Allow for multiple content views, enable resizing and rearranging of content tiles or panels.
• Support user agency: Don’t override user customizations with system-automated personalization or admin-controlled updates.
• Avoid using multiple browser tabs and windows: If required, ensure system information is passed easily between tabs.

The prevalence of neurodivergence is increasing. Focusing on the support needs of neurodivergent people will improve the overall experience for everyone. Doing so now will solve issues for the next generation of users (and buyers).

Incorporating Accessibility into SEQ Usability Testing: Designing for Inclusive Experiences

Speakers: 
Rebecca Topps, Senior Accessibility Researcher, Atlassian
Alison Williams, Lead UX Researcher, Atlassian

Summary/Insights: Haley Troyer

In the final design talk of the day, Rebecca Topps and Alison Williams discuss their experience combining their SEQ testing efforts with accessibility research.

SEQ stands for Single Ease Question. It’s a question that a researcher asks a participant in a usability study to determine how difficult or easy it was for them complete a single task. The participant provides a score between 1 (very difficult) and 7 (very easy). A score of 5.5 is considered average, so you can use that to determine whether your tasks are above or below average in terms of ease of use.

How it works

• The moderator asks the participant to complete a task, but does not lead them in any way
• The participant performs the task
• The moderator takes notes of issues, failures, successes, etc.
• At the end of the task, the participant answers the SEQ for that task

Research process

• Recruit a panel of real users with disabilities
• Ask participants about the assistive technologies they use as well as any accommodations they may need during the test
• Made sure screener and consent forms are accessible, and send them out in advance so participants have time to complete them
• Ran automated testing on all SEQ tasks prior to the test, ensuring there are no accessibility blockers that would prevent a task from being completed
• Perform the test
• Ask for feedback about the testing process
• Compile and deliver results!

Tips for delivering results

• Include screenshots and video of assistive technology being used to educate teams on how AT works and how people use it
• Provide real quotes from users to establish empathy

I’m always fascinated to see how companies handle user research and usability testing on large-scale apps with many features and teams. I can definitely see myself integrated SEQ Usability Testing into our projects, though likely on a much smaller scale.

The European Accessibility Act (EAA): Why it’s here and how you can prepare for it

Speakers:
Inmaculada Placencia Porrero, Senior Expert on Disability, The European Commission
Alejandro Moledo, Deputy Director, European Disability Forum (EDF)

Summary/Insights: Riley Rittenhouse

Inma explained that The European Accessibility Act includes a set of accessibility requirements for carefully selected products and services, these requirements will then be used in other EU laws. These services include consumer general purpose hardware systems and operating systems, self service terminals, consumer terminal equipment with interactive computing capability used for electronic communication services, and for accessing audio-visual media services, as well as e-readers. The first deadline will be in June of this year.

It was interesting to hear about the legislation side of things and how the EAA changed over time as it went through all the different channels to get it implemented. It sounded like quite a bit was cut out, and example that Alejandro used was that the ATMs at banks need to be accessible but the building itself does not. Even though some elements are no longer part of it, I still think this is a good step forward and I’m interested to see how the EAA will affect global accessibility in the future.

I did think it was important that they mentioned companies from the US that have services in the EU market will need to meet these requirements by June 28th and if they don’t they could face fines for it.

Design For Everyone

Speaker:
Laura Kalbag, Senior UX Designer and Front-end Developer, Technical Writer, and Speaker

Summary/Insights: Riley Rittenhouse

Laura shared a checklist she created for her design process that incorporated the WCAG criteria but in more plain language. This included items like color contrast, not using color alone to convey meaning, using straightforward layouts, and using alt text for images. I really appreciated how Laura broke down each section and talked about items individually, this would be great for anyone who is just getting into accessibility to listen to. Unfortunately some technical issues ended this one a little early so I’ll need to go back to listen to the very end and the ethics part of it.

I like the idea of having some sort of checklist, but it’s important to acknowledge the limitations of it. Not everyone falls into one simple category, so designs should be flexible and have multiple ways to complete an action. I’m interested in seeing if there are any Figma plugins that could act as a checklist. There were so many great quotes from Laura, two that really stuck with me are:

“Accessible design is not just about inclusion, but specifically about not excluding people.”

“Interfaces aren’t escape rooms.”

Shift Left: Crafting a Rock-Solid Accessibility Workflow for Beginners

Speaker:
Ben Allen, Sr. Product Manager, Deque Systems, Inc.

Summary/Insights: Riley Rittenhouse

Ben walked through a few different demos in VS Code, Google Chrome, Cypress, GitHub Actions and Slack and some integrations with axe DevTools that can be added to each for accessibility testing. It was noted that some of these features he shared are a premium or paid feature for axe DevTools.

• VS Code and axe DevTools Linter: Quickly showed errors that included links to Deque for each issue found and explained how to fix these issues.
• Google Chrome with axe DevTools extension: Prioritizes issues from critical to minor. Scans can be done for a full page or partial, as well as through guided tests. I’ve used this before for accessibility testing, but one new aspect they went through was User Analysis Testing which allows you to interact with elements on the page and it does more of an in depth accessibility test.

I’ve seen several of these tools before, and I know we have started implementing some of these tests into our workflow. It was interesting to see the Slack integration for axe Assistant. In the example Ben showed the assistant creating alt text for an image. I believe this was the first time they have shown it, so I’m interested to see what features it will include in the future.

From Parts to Whole – Beyond Design System

Speaker:
Sayali Bharambe, Experience Designer, Deutsche Telekom

Summary/Insights: Riley Rittenhouse

First of all I really loved seeing all the illustrations in this presentation. Sayali talked about the importance for creating design systems and component libraries that can be used by everyone on the team so that they aren’t constantly reinventing the wheel. She also mentioned annotating these components so that they are developed with accessibility in mind and also to do multiple checks along the way and find what they need when they need it. A design system should include templates, annotation kits and guides, and tools to check for accessibility at every level of design and development. 

I liked that she mentioned how different stakeholders and roles in the development process can all contribute to making accessibility a key part of any experience. Also that we all learn in different ways so making these guides available in multiple ways for people to understand.

Unboxing Accessibility: The Dangers of a Restricted View

Speaker:
Michele Williams, UX & Accessibility Consultant, M.A.W. Consulting, LLC

Summary/Insights: Riley Rittenhouse

Michele explained the idea that many people have that accessibility needs to fit into a box or the WCAG criteria is a checklist that should be tacked on afterwards. This thought process really limits our creativity and can often leave a lot of people out of the discussion. Instead of being so rigid in our accessibility standards, we should look at them as the starting point and be able to innovate beyond that. 

I think what Michele talked about is especially important in emerging technologies like AI. This isn’t necessarily a large part of WCAG standards because it’s still relatively new, but that shouldn’t stop us from making sure that we’re advocating alongside people with disabilities to call out areas that aren’t accessible for everyone.

3 Dimensions for Inclusive and Accessible AI

Speaker:
Ailsa Leen, Principal Program Manager, Microsoft

Summary/Insights: Riley Rittenhouse

I was really looking forward to hearing more about accessibility initiatives in generative AI. It was great to hear from someone who is directly in the AI/accessibly area. Ailsa talked about the importance for AI making a difference for those in the disability community, and how bringing them into the conversation around AI can help create a foundation for making AI something that everyone is able to interact with.

The three dimensions she described were:

• AI/ML industry - Who gets to build with AI?
• Models/systems - Are the models and systems inclusive?
• Innovation - What can AI do for inclusivity?

She briefly talked about the Speech Accessibility Project that is currently researching and building a dataset needed to more effectively train machine learning models for speech recognition. This is especially important for those with diverse speech patterns and disabilities. It will be interesting to see where that goes in the future.

Automation Gains: Increasing what can be automated in accessibility testing

Speaker:
Harris Schneiderman, Senior Product Manager, Deque Systems

Summary/Insights: Riley Rittenhouse

This session was another look at the axe DevTools and some new features that have been added to their automated accessibility testing tools.

• Advanced Automated Rules - takes automated coverage beyond 57% with 0 false positives
• User Flow Analysis - feature in browser extension
  • Test entire user journeys through complex multi-page/multi-state flows
• IGT Auto Reply
  • Intelligent Guided tests - semi-automated tests that asks your team simple questions about your app and run complex accessibility checks in the background
  • Train the IGT once
  • Detects changes, fixes and regressions automatically
• Axe Assistant - AI Remediation Guidance
  • Gives context-specific guidance on how to fix your accessibility issues

Out of all the tools he went through, I think I’m most excited for the User Flow Analysis within the axe DevTools browser extension that will help in testing the different interactive states of a page. This will be useful for different interactive components like modals or accordions in testing the keyboard functionality of those.

Day two conclusion

After such an exciting day one of the conference, today was just as exciting, with a recurring theme of the European Accessibility Act (EAA).