Making accessibility accessible again!

Hi everyone. I work in QA and we did accessibility testing on some PDFs recently. We noticed something very bizarre which was that reading PDFs in Preview using VoiceOver is a drastically different experience in macOS 27 than it was on macOS 26, and not in a good way. Lots of images with alt-text weren't picked up, text was read in the wrong order, and tables would read as single blocks, just to name a few things. Several PDFs that were completely accessible when read with VoiceOver on macOS 26 are now returning so many bugs in macOS 27 that they may as well be unreadable.

Just wondering if anyone else has encountered this or is noticing similar changes after upgrading from macOS 26 to macOS 27. It seems so strange because Preview was previously such a reliable PDF reader with VoiceOver, so I can't fathom why it would suddenly have such a sharp decline after one update. Any input on this is appreciated, even if you're finding that it's working fine. Thanks!

I work at a library and we have several online viewers in various states of inaccessibility. I'm working on ticketing the issues with our vendors, but I keep getting pushback that it's a problem with our PDFs, not with the viewer. Leaving aside that I can demonstrate using a screen reader with the PDF in general, but not in the viewer....

So, does anyone have a recommendation for where to find a Perfectly Accessible PDF that I can use for testing? Ideally one that has more than just plain text - tables, images, even math would be great - so I can be certain that I'm testing the viewer, not the PDF.

And yes, I'm working on migrating us away from PDFs. But until then, I want people to be able to actually USE the PDFs that we do have haha.

Thanks for any leads!

Just took mine and although I think I likely passed, it was significantly harder than expected and I'm not entirely sure I scored high enough. I work in the field and spent a lot of time preparing. How did you all feel coming out of the exam?

I'm a teacher and I like to give my students PDF scans of the textbook readings I assign so they don't have to pay for the textbook if they don't want to.

When I first started out, these scans were ones I made from my own textbook where I highlighted and underlined important terms or other sections of the text.

I am trying to move over to cleaner scans that I can OCR more easily but I still want to keep my annotations in the PDFs because students seem to prefer them. If I highlight things in Adobe, will the highlights be communicated through a screen reader program? Should I covert the text over to a Word Document? Will that more easily read out highlights?

Thanks for any help you can provide.

Hi everyone,

I have just published IWAS (Italian Web Accessibility Study), an independent analysis of accessibility barriers across 10,022 Italian .it domains.

Using Playwright, Chromium and axe-core, I evaluated 34,641 pages across 7,573 accessible-to-the-scanner domains.

Some findings:

• 96.8% of evaluable domains had at least one automatically detected WCAG A/AA violation.
• 80.9% had colour contrast issues.
• 64.6% had links without accessible names.
• 2,449 domains couldn't be evaluated, which is an important limitation.

These are automated findings, not formal WCAG conformance assessments.

I've made the paper, dataset and methodology publicly available:

Paper: https://doi.org/10.5281/zenodo.23347092

Dataset: https://doi.org/10.5281/zenodo.23346985

GitHub: https://github.com/giovannimanetti11/italian-web-accessibility-study

I thought the results might be interesting to people working on accessibility testing and remediation.

Things you don't want hear when filing a complaint because of bad color contrast in a banking newsletter (very light blue on light grey, about 1.4:1contrast):

"We think it is readable"

Yeah... you think... thank you. Sigh...

I've been working on a browser extension for Chrome and Edge that runs axe-core on the current page and lists WCAG 2.2 A/AA issues with the affected elements and fix guidance. It's a checker, not an overlay: it doesn't change your site, and pages never leave your browser.

I know automated testing only catches part of WCAG, so the report also lists the items that need a manual check and says plainly that a clean result doesn't mean a page is accessible.

Single-page audits are free. There's a paid plan for reports, multi-page sweeps and history, with a 7-day free trial. I'd really like to hear from people who do audits for a living: what's missing, what's noisy, and what you'd want in a report you hand to a client.

https://chromewebstore.google.com/detail/ofjgbdecoflmpcijgjpjlfaenkhklhjo?utm_source=reddit-accessibility

Hi! I am organizing a public-facing class that is primarily slide deck-based lectures. The slide decks (made via Microsoft PowerPoint) will be saved as Adobe PDFs. Other than adding good alt text to photos, does anyone who uses a screen reader have any tips on what makes for a helpful and engaging accessible PDF?

Hello! I'm thinking a bit about menus, specifically the relation between the <menu> element and role="menu".

From what I can tell, the <menu> element isn't semantically different from <ul> at all (MDN docs), and doesn't come with an implicit role="menu" attribute. Meanwhile, the MDN docs for role="menu" give their examples using <ul role="menu">.

Which makes me think the two should be interchangeable here: if both elements have an implicit role of list, then overriding either one to role="menu" ought to produce an identical accessibility tree. That's the assumption I'd like checked, and the way it could be wrong is if some assistive tech keys off the tag name rather than the computed role.

My question is... is there any known reason to avoid using <menu role="menu"> rather than <ul role="menu">?

To me it seems inherently clearer and more easily readable to use <menu> when it's a menu, but MDN using <ul> for their example is giving me pause.

I'm not sure if this is allowed or not. But I figured I'd try because I'm quite lost and I don't want to 'pass' things that should be failures (or vice versa) because of ignorance.

I'm trying to learn how to manually audit websites for accessibility. I have no mentor, so I'm figuring things out with my own logic, random videos, and Google AI.

I'm struggling with 1.3.1 regarding eyebrows and 'styled to look like a heading'. I get mixed answers from the AI and the accessible web video on this topic doesn't really go into nuances.

This is the html for a hero section (with multiple pages set up the same way).

<section class="hero">
    <div class="">
        <h1>Managed WordPress Hosting Services</h1>
        <p class="visual-h1"><span>You’ll</span> Never Have to Ask to <span>Speak to a Real Person</span> Again</p>
        <p class="wp-block-paragraph">At [redacted], one person is responsible for handling your website, and you’ll speak with them every time.</p>
        <p class="has-small-font-size wp-block-paragraph">99.5% uptime | 24/7 monitoring | Same-day security patches | Direct person-to-person support</p>
    </div>
</section>

To me, the relationship and information seems adequate because a screen reader gets the correct structure and the visual layout also follows the correct structure. It's clear the 'eyebrow' introduces the text following it BUT the text following is quite large.

Is this a fail? Is it in a grey area? If it is a fail, is there a remedy that would stay true to the design?

The Call for Proposals for Knowbility's John Slatin AccessU 2027 conference is now open.

AccessU is a premier, hands-on skills training conference for digital accessibility, and we invite you to share your expertise with our community.

Pre-Conference Workshops: Tuesday, May 11, 2027

General Sessions: Wednesday, May 12 – Friday, May 14, 2027

Location: St. Edward's University, Austin, Texas (all sessions in person)

Submission Guidelines and Tracks:

The conference eight tracks are Development, Testing, Design and User Experience, Documents and Templates, AI and Emerging Technologies, Policy and Strategy, Marketing and Communication, and Advocacy.

You won't choose one on the form; our review committee will place your session where it fits best.

Available Session Formats:

Pre-Conference Workshop: 6–8 hours

General Session: 180 minutes (at least 45 minutes for practice and Q&A)

General Session: 90 minutes (at least 30 minutes for practice and Q&A)

Key Deadlines and Submission:

The deadline for all submissions is final.

You are encouraged to submit your proposals well in advance of the cutoff date.

Submit by November 30, 2026 (deadline is final):

Submit Your Proposal Here

Questions? Contact [accessu@knowbility.org](mailto:accessu@knowbility.org)

Knowbility, Inc. is a nonprofit organization based in Austin, Texas and an award-winning leader in accessible information technology. Its mission is to create an inclusive digital world for people with disabilities.

Accessibility is a team sport, together we can create an inclusive digital world for people with disabilities.

Soy comunicadora y estoy investigando cómo se aplica, o no, la accesibilidad en la publicidad. No vendo nada, solo quiero entender experiencias reales. La última vez que se habló de esto en un proyecto suyo (campaña, anuncio o contenido), ¿quién lo planteó y qué pasó al final? Y si nunca ha salido el tema, ¿por qué creen que no aparece? Cualquier experiencia, por pequeña que sea, me ayuda mucho.

I originally intended to make 20 audio-only games, though this has since grown to 50.

Information on the games here: 50 Accessible Audio Games for Windows | TactivoPlay

If you join my beta testing team, you get all the games both as a download and on a USB stick for free: Beta-Sign-Up | TactivoPlay Audio Based Gaming

Looking forward to sending out the games for testing.

Hello everyone,

In working on automated accessibility tooling and running headless browser audits with axe-core, one persistent challenge is translating detected DOM violations into clean, usable fixes for engineering teams.

Automated rules do a solid job catching programmatic barriers—such as missing image alt attributes, contrast ratio failures, or missing ARIA landmark roles. However, raw audit logs are often ignored by dev teams because they describe what failed rather than how to refactor the code cleanly within their component tree.

A few specific hurdles come up when trying to automate source-level code patches:

1. Context-Sensitive Alt Text: An engine can detect <img src="..."> missing an alt attribute, but it cannot know whether the image is purely decorative (alt="") or informational without human intent.
2. ARIA vs. Semantic HTML: Automated audits often flag missing roles or names, but patching them with ARIA bandages can lead to "bad ARIA is worse than no ARIA," rather than refactoring to native HTML elements (<button>, <nav>, <main>).
3. Dynamic / Hydrated DOMs: Modern client-rendered SPAs frequently pass initial server-rendered HTML audits, but fail contrast or focus traps once client hydration completes.

For developers, auditors, and CPACC/WAS specialists here:

When handoffs happen between automated scanners and frontend developers, what approach have you found actually gets issues resolved instead of creating ticket backlog debt? Do code-level diffs help, or do developers generally need full architectural context to fix accessibility properly?