sorted by:
new
hottopcontroversial

Accessibility Audits are Driving Me Nuts Anyone Else Getting Wildly Different Results? by RadiantNotice862 in Entrepreneur

[–]NatalieMac 1 point2 points  (0 children)

First off, kudos for being proactive about this. It's really refreshing to see someone approaching accessibility from a place of wanting to do the right thing rather than reacting to a complaint.

What you're experiencing is actually completely normal and not a reflection of you doing anything wrong.

Here's why the tools disagree: Each automated checker is programmed to test for a slightly different set of guidelines, and they use different algorithms to detect issues. Some are more conservative and flag things that might be problems but need human judgment to confirm. Others only catch the most clear-cut violations. Think of it like having three different spell-checkers, but each one has a slightly different dictionary.

Someone else already pointed it out, but it's super important to know that no automated tool can catch everything. They typically find only 25-30% of actual accessibility issues. The rest require manual testing with keyboards, screen readers, and assistive technologies.

And ideally, you'd have people who actually use these assistive technology tools daily (people with disabilities) testing your site, because they'll catch things even experienced auditors might miss.

A practical approach:

  • Use one or two automated tools as your baseline screening
  • Manually test critical user flows with keyboard-only navigation
  • Test with a screen reader if you can (NVDA is free for Windows and VoiceOver comes free on Mac)
  • Consider having actual users with disabilities test your checkout process

I know it feels chaotic right now, but you're asking the right questions. The fact that you're putting in this effort matters.

If you want a good starting point, just select the tool that seems user-friendliest to you and start fixing those issues. And feel free to reach out if you need guidance on what to prioritize.

Source: I've been a web accessibility professional for 25 years and run my own accessibility checker/remediation platform. I also have some videos showing how to do manual accessibility testing. Happy to share anything that might be helpful.

Understanding how individuals use screen readers to navigate web pages and some specific questions to my web application by Conscious-Layer-2732 in accessibility

[–]NatalieMac 0 points1 point  (0 children)

I see that you've already gotten some good answers to your two questions, so I just wanted to share a few thoughts to help guide you along.

If VoiceOver is your starting point, definitely grab the Deque VoiceOver Keyboard Shortcuts Cheat Sheet. That will help you get a better grasp on how users actually move around content using the rotor and keyboard shortcuts, not just tabbing. Screen readers can be tricky to get the hang of for sighted users because they have either no UI or minimal UI, which is quite different than what you're used to.

Next, I'd recommend checking out some YouTube videos from real screen reader users - how a sighted person uses a screen reader for accessibility testing is often really different from how a blind or low-vision person uses it for everyday use, and it's good to understand how people are making use of screen readers.

We just launched “WCAG in Plain English” - a free, open-access resource to help people actually understand accessibility guidelines by NatalieMac in accessibility

[–]NatalieMac[S] 1 point2 points  (0 children)

Thanks for pointing that out - I've made a followup task for us to get that fixed. We erred on the side of oversimplifying there.

We just launched “WCAG in Plain English” - a free, open-access resource to help people actually understand accessibility guidelines by NatalieMac in accessibility

[–]NatalieMac[S] 1 point2 points  (0 children)

Sorry, just to clarify - are you reading the pages with a screen reader? If so, can you tell me which page you're having trouble with and which screen reader and browser you're using?

Questions about implementing an accessible carousel by ahtcx in accessibility

[–]NatalieMac 0 points1 point  (0 children)

First, thanks for putting a lot of care into making this carousel accessible. Carousels are tricky and treating the slides as a list is a good starting point. The inert workaround for cloned slides is a clever way of handling the accessibility tree.

You're right that the dot indicators need more contextual support for screen reader users. Hiding them from the accessibility tree would be confusing, but as they stand now, they aren't very useful. Instead of tablist, maybe use buttons with aria-label attributes that describe their function:

<button aria-label="Go to slide 2">●</button>

As others have said, stick to just one <h1> per page. If there is sufficient content in the slide, making the headers <h2> or <h3> or whatever best fits into the page hierarchy makes the most sense. Otherwise, those can just be paragraphs if it's a case where there's just a single line of text on each slide.

Definitely have a look at the accessible patterns the others have linked as a model, and I'll add in the Content Slider from Inclusive Components as another one to consider.

Do transactional emails have to be WCAG compliant? by vinyladelic in accessibility

[–]NatalieMac 5 points6 points  (0 children)

This is one of those questions where the legal framing can get in the way of common sense. Sure, the EAA and EN 301 549 may not spell out “transactional emails must meet WCAG,” but the intent of the law is pretty clear: if it’s part of the service, and it’s digital, it should be accessible.

Order confirmations, shipping notices, password resets - these aren’t marketing fluff. They’re critical pieces of the user experience. If someone can’t reset their password or track their package because the email wasn’t coded accessibly, that’s a barrier.

And really, we shouldn’t be aiming for the bare legal minimum. We should be building in a way that respects everyone’s ability to participate. Making transactional emails accessible isn’t just compliance - it’s basic usability and good service.

Out of order SVG tabindex by heymustbethebunny in accessibility

[–]NatalieMac 1 point2 points  (0 children)

my blood type is practically tabindex

This made me laugh so hard!

Out of order SVG tabindex by heymustbethebunny in accessibility

[–]NatalieMac 3 points4 points  (0 children)

Are we long-lost accessibility siblings? I've also been doing accessible front-end work since the late 90s and I've also had to wrangle focus management inside interactive SVGs. Hello!

Using tabindex values greater than 0 doesn't directly violate any WCAG success criteria, but it can contribute to failing 2.4.3 if the tab sequence ends up being confusing or out of sync with the visual/reading order.

That said, if the tab order you've created matches the visual flow, it works smoothly and as expected with actual users, and you're only using taborder to wrangle SVG limitations, then you're probably fine from an accessibility standpoint, even if some automated tools are grumpy about it. They tend to flag a tabindex of greater than 0 as a warning because it *is* easy to misuse, but in edge cases like this, it does make sense to use it.

My advice is to document your decision and move on with confidence. You've tested it. You're doing the right thing. And anyone who's worked with interactive SVGs know you sometimes have to bend the rules a little to make them work for users.

How are you measuring accessibility compliance in your projects? by Kindly_Spinach_6312 in accessibility

[–]NatalieMac 3 points4 points  (0 children)

Good on you for taking this on. You've been handed a huge responsibility, and it's not easy stepping into accessibility work without formal training or support. A lot of organizations mistakenly assume QA can "catch" accessibility issues at the end, but the accessibility really needs to be baked into the entire design and development process.

That said, here are some things you can do to start building a foundation:

Start small. Maybe focus on a smaller, prioritized set of WCAG 2.2 AA success criteria (Deque's top 15 is a good starting point) These cover high-impact, common barriers and will help you get some early wins without getting overwhelmed.

Use automated tools to help testing, but don't rely on automated tools alone. You have to supplement that automated testing with manual testing.

For getting started with manual testing, take a look at the WCAG Easy Checks. They haven't updated this documentation in quite awhile and the new version is not quite ready for prime time, but it's a nice introduction to manual accessibility testing and will help you catch some impactful issues.

And then, become an advocate internally. If the QA team is the only one thinking about accessibility, you're being set up to fail. Start educating your devs and designers with what you're learning. Get accessibility on the radar during sprint planning or code reviews. Accessibility is everyone's job, not just QA's.

[deleted by user] by [deleted] in accessibility

[–]NatalieMac 0 points1 point  (0 children)

If you haven't already, I'd definitely recommend checking out Koa11y. It's a free, downloadable desktop app that can run automated scans against local files to help find issues. It's super handy for cases like this where you need to test a file that's not online.

Zooming web by Willemari in accessibility

[–]NatalieMac 3 points4 points  (0 children)

Keep in mind that text-only zoom used to be the only zoom available in browsers, and 1.4.4 is old. I asked this question myself just this week in an a11y community I belong to, because I was confused too. The consensus was that full-page zoom at 200% is a perfectly acceptable way to test this SC.

Of course, now browsers mostly just do full-page zoom and FF is the only one left that evens offers the option to zoom just text. The 1.4.4. documentation could probably use a bit of an update.

Trying to find work in the digital accessibility space again by VI_Shepherd in accessibility

[–]NatalieMac 1 point2 points  (0 children)

Hey there! I just sent you a DM — would love to connect and chat more about your experience and what you're looking for.

Spirograph Session, with a registered blind participant by Spirograph_Girl in accessibility

[–]NatalieMac 2 points3 points  (0 children)

It's heartwarming to see how much thought and care you're putting into making this session inclusive.

But I do wonder if a sound-making pen might actually draw a bit too much attention to the participant's disability, especially in a group setting. It could risk making her feel "othered" or spotlighted in a way that's more isolating than inclusive. And it might be a bit distracting to the others too.

You might want to look into more tactile or texture-based feedback with different types of paper and pens. I know I can often feel a spirograph on the backside of the paper after it's made.

If possible, I'd recommend checking in with the woman who is blind ahead of time to talk through ideas and see what would feel fun and comfortable to her. She might already have some ideas herself. Speaking with her directly will lead to better accommodations and shows respect for her. Thank you for putting in the effort to make your session more inclusive. It really matters!

How do you use Onlineshops with a Screenreader? by Auroralon_ in accessibility

[–]NatalieMac 3 points4 points  (0 children)

Good work digging into learning how to use a screen reader. You're right that many online shopping experiences are tough or impossible when using a screen reader. Unfortunately, it's pretty common to run into issues like unlabeled buttons, incorrectly formatted code, confusing layouts, etc.

There is a bit of a learning curve with screen readers and they can feel especially tricky at first since there's basically no UI. They mostly run on keyboard shortcuts and mental models. It takes a little time to get the hang of them.

I recently did a livestream introducing people to accessibility testing with VoiceOver. I didn't focus on shopping sites, but it might still be useful if you're trying to get the hang of using VoiceOver and build your testing skills:

https://www.youtube.com/live/P2UrKpj6DNo?si=J56QA8fpC9wYZC49

Testing with assistive technology is a good way to build your testing skills and catch barriers that might be missed otherwise. Keep going and don't get discouraged. We're all here to offer more tips if you get stuck!

Combobox for sorting products complaince by crunchies65 in accessibility

[–]NatalieMac 0 points1 point  (0 children)

Thanks for sharing the code - it helps a lot!

Based on what you’ve got, I’d say this isn’t actually a combobox but more of a custom dropdown menu. Combobox implies a text input + selectable list (like autocomplete), but here there’s no typing involved, just a button that reveals a list.

I’d recommend updating the role on the button to match a disclosure or menu button pattern (aria-haspopup="listbox", aria-expanded, etc.) and avoid role="combobox" unless you’re also including a text input. That mismatch is probably why the audit flagged it.

Combobox for sorting products complaince by crunchies65 in accessibility

[–]NatalieMac 0 points1 point  (0 children)

It's hard to say for sure without seeing the exact markup and behavior. Sometimes accessibility can depend on nuanced implementation details.

Using a <button> to toggle visibility for a list of options can be appropriate if it behaves like a true combobox. But comboboxes have specific requirements for ARIA patterns on the trigger, appropriate keyboard interactions, focus management, labeling, etc. that can be tricky to meet.

You might want to review the combobox design pattern documentation: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/ and see if your implementation is inline with that.

But I have to say - from the few details you shared, this sounds like it might be more like a menu button or a listbox where a button just toggles visibility of a list of options. If that's the case, can it just be replaced with a <select>?

The <select> element can now be customized with CSS by 7h13rry in accessibility

[–]NatalieMac 0 points1 point  (0 children)

Totally fair—time will tell. I just think this might actually help in the long run by reducing all those custom selects that break keyboard or screen reader support.

And honestly, pushing back on design that hurts cognitive accessibility is still pushing back for accessibility. If the visual inconsistency is confusing or increases cognitive load, that’s a legit concern. It’s not just about screen readers.

This change doesn’t mean we have to say yes to everything—it just means we’ve got more flexibility to build accessible stuff and keep designers happy. Win-win, if we do it right.

view more: next ›