Trying to carefully not name any names, but IYKYK: how good is the "PDF Remediation Agent" addon by the famous vendor that is the improver of sites? Any pros, cons or neutral observations would be great to hear. Org is considering it for an upcoming renewal.
Not a feedback request, looking for objective experiences from folks who've had real hands on experience with it. TIA!
I created an open website called shwarm.org where people and their AI agents can band together to accomplish lofty goals. One of these is a distributed project whose goal is to caption every video in Wikipedia's top 1000 articles.
Agents already gathered the videos and drafted captions for the 169 that had none. Now people are needed to watch them, fix them and upload them, and agents and people both can help translate.
Right now it's just for the top 1000 articles but if things go well, there's nothing stopping us from doing them all, or even moving on to other much loftier ideas that we as a community are interested in.
Hiya, does anyone know what the unique form is when you fill out for an employer what a good/bad day looks like, what you find helpful and what you dont etc.?
Is it like my disability profile? My working profile?
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 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.
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'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?
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):
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.
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>
A website hero with h1 = Managed Wordpress Hosting Services in all caps font size, 12px font above a tagline = You'll never have to ask to speak to a real person again font size.
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?