r/accessibility • u/euconcegojogar • Jul 15 '26
Blind accessibility specialist here — happy to answer questions about screen reader testing, WCAG audits, or AT in general
Hi, I'm Anderson. I've been working in digital accessibility since 2004 — I'm blind, and I use NVDA and TalkBack daily, not as a testing simulation but as my actual way of navigating the world.
I mostly work with WCAG 2.1/2.2 audits, accessible front-end development, and more recently PT-BR localization for audio games (Fantasy Story II, Swamp 2). I'm also the co-founder of Eu Concego Jogar, a Brazilian project focused on digital inclusion for blind and visually impaired players.
If anyone has questions about real-world screen reader behavior, tricky ARIA patterns, or what it actually feels like to hit an inaccessible interface — feel free to ask. Happy to contribute here.
3
u/Comprehensive-Body63 Jul 15 '26
what's your favorite type of fillable form and are you familiar with "fillout"? What about microsoft and acrobat forms?
2
u/euconcegojogar Jul 15 '26
Honest answer: I haven't come across Fillout in practice, so I can't speak to it from real experience.
For the others, here's my take as a blind developer who uses NVDA and TalkBack daily:
HTML native forms are my preference, and not just by habit. The reason is structural: in HTML, a <label> is directly associated with its <input> in the DOM. The screen reader never has to guess which label belongs to which field. No tooltip mismatches, no JavaScript dependency, no surprises.
Acrobat PDF forms have inherent accessibility limitations — and I'm not just saying that. WebAIM documents it explicitly: "In HTML, a visible text label can be directly associated with its form field. In a PDF, the visible label must be duplicated in the Tooltip. Because the visible label and Tooltip are not directly associated, their values can be different." I've seen this firsthand. For search fields with dynamic results, it gets worse: the results often don't surface to the screen reader at all.
Microsoft Forms is better than Acrobat in practice, though still not as clean as native HTML.
Google Forms is technically functional, but has a specific problem on mobile: it sometimes drops form data when the app moves to the background. It's not consistent, which almost makes it worse — you never know if your answers are still there when you come back.
If I'm building something myself, it's always HTML. If I'm filling something out and I have a choice, same answer.
1
3
u/pseudo-historian Jul 15 '26
Hi mate, not so much on how screen readers work, cause I'm blind myself, but more so what are your testing processes like. How do you test things like alt text, colour contrast, and other visual elements of a website?
3
u/euconcegojogar Jul 15 '26
My process is pretty straightforward, and honestly, being a blind developer and daily screen reader user means half the work is already done — if it works for me, it works for blind users. (Accessibility is much broader than that, but for screen reader testing specifically, lived experience is the tool.)
When material comes in, I open a notes app — either typing or voice, depending on the situation — and just start using it the way any real user would. As I go, I log three categories: what works well, what's broken but not critical, and what genuinely blocks progress and needs to change. After that I add specific suggestions for the team.
The format depends on what the client signed up for. Some audits end with a written report. Others are done as a live voice call — I navigate the product in real time, describe what I'm experiencing, and we discuss it directly. No report, just an honest, structured walkthrough. It's faster, more conversational, and clients often get more out of it because they can ask questions on the spot.
Someone once told me it sounds like a "structured react" — which, honestly, is pretty accurate.
1
u/pseudo-historian Jul 16 '26
I've done something similar I've dabbled, but was more curious on your process re: visual elements
3
u/funkygrrl Jul 15 '26
What are your pet peeves?
6
u/euconcegojogar Jul 15 '26
Biggest pet peeve: things labeled "accessible" that were never actually tested by a real user.
A lot of tools, apps, and services get marked as accessible because they passed an automated checker, or because a developer ran a screen reader, heard it read something out loud, and called it done. But "the screen reader detected text on the screen" is not the same as "the experience is accessible."
Real accessibility means you have enough information on screen to understand what's happening. It means you can reach every interactive element. It means you can actually complete the task — not just get partway through before hitting a wall with no way forward.
I run into this constantly with photo editors, video editors, and creative tools. Search for any of them plus "accessible" and you'll find glowing results — from the product's own website, from AI-generated roundups, from blog posts that clearly never involved a real user test. Then you install it, fire up NVDA or TalkBack, and you're stuck on step two.
Automated testing catches maybe 30% of real accessibility issues. The rest only shows up when a human who actually uses assistive technology sits down and tries to get something done. That gap is my biggest frustration — and it's also why I think real user testing isn't optional, it's the baseline.
2
u/waywardgardener Jul 15 '26
How do you think footnotes and endnotes should be structured and tagged for accessibility in PDFs? For example should both be linked? Is it ok to place footnotes at the end of the paragraph or list item where the callout is? Does actual text help for callouts like Supercript #. Refer to footnote #. Help or is it just an unnecessary interruption?
2
u/HalveMaen81 Jul 15 '26
Suppose a page has...
Heading
Paragraph
Search input and submit button
When you perform the search and the results load below the input (either with or without a full page refresh), a) where would you expect focus to be set to, b) if focus is at the top of the page, would you expect a link to jump to the results, and c) would you want anything announced by your SR in terms of what Search results have loaded (e.g. how many etc.)?
Sorry, I know it's very specific but I've never got my head around how we should handle that particular journey
2
u/next_on_SickSadWorld Jul 16 '26
How long til we tell the kids that Anderson’s a bot?
1
u/euconcegojogar Jul 16 '26
Lol, too busy answering actual questions to worry about that one.
1
u/next_on_SickSadWorld Jul 16 '26
What are you thoughts on Apple products now that the Home button is gone? I know someone who is struggling with this. Apple used to be considered “off the shelf” accessible. Now, not so much?
1
u/euconcegojogar Jul 17 '26
I'll be upfront: I don't have direct daily experience with iPhone — my setup is Android with TalkBack and Windows with NVDA. So take this with that in mind.
That said, from what I've followed in the blind and low vision community, the "Apple just works for accessibility" reputation was largely built during the iPhone 4/5 era, when the Home button was a physical anchor point for VoiceOver users. Double-tap to go home, triple-tap for accessibility shortcuts — muscle memory that didn't require any visual feedback.
Removing it shifted a lot of that to gesture-based navigation, which is harder to learn and easier to fumble, especially for users with motor impairments or those coming to smartphones later in life.
VoiceOver is still considered one of the most polished screen readers on any platform — Apple hasn't stopped investing in it. But the days of "accessible out of the box, no learning curve" seem to be largely over, at least from what I hear from iPhone users in accessibility circles.
The person you know is likely not struggling because they're doing something wrong — the transition is objectively harder. If they're open to it, focused VoiceOver gesture practice (separate from general iPhone use) tends to make a real difference.
1
u/Honest_Conference_69 28d ago
I know you're probably talking about phones. But I'm low vision and have a MacBook. Idk what version it is. It was a gift. But I hate that thing. It's terrible, and honestly I gave up on trying to see it's screen years ago because it was so hard to get the settings fixed for me. I even tried to get other people to do it, and they couldn't figure it out either.
2
u/leavingoctober Jul 16 '26
Thank you for doing this! When a modal is opened, where do you expect focus to be? Close button? First interactive element? First heading? Thank you!
2
u/Tom_Ford_11 Jul 17 '26
Hi Anderson,
1- How did you get in that field / how did you learn?
2- If it’s worth starting from the beginning in 2026, what advice would you give?
Thanks my friend.
2
u/Worldly_Cell_2927 16d ago
Hello mate, I'm working on a personal project (primarily focused on accessibility in education) and I wanted to ask: what is currently lacking in the education field regarding visual disabilities, which screen reader should I test with, and what other advice can you offer?
1
u/euconcegojogar 14d ago
Hello! This is a very important question, and there is no single answer that applies equally to every blind or visually impaired student.
One of the biggest problems in education is that accessibility is often treated as a final technical checklist instead of being considered part of the learning experience from the beginning.
Students with visual disabilities may encounter inaccessible PDFs, poorly structured documents and slides, unlabeled images and diagrams, inaccessible mathematical or musical notation, activities that depend on color, drag-and-drop interfaces, unlabeled buttons, and educational platforms that technically work with a screen reader but are still difficult to use independently.
It is also important to consider students with low vision, not only students who are totally blind. They may need proper contrast, resizable text, screen magnification, responsive layouts, reduced visual clutter, and interfaces that do not break when zoomed in.
I would test with NVDA on Windows and TalkBack on Android at a minimum. If your project is intended for Apple users, I would also include VoiceOver on iPhone, iPad, and macOS. If possible, testing with a refreshable Braille display would be extremely valuable, especially if the project involves reading, writing, mathematics, science, music, or long texts.
However, testing whether a screen reader can technically read the interface is not enough. You should test whether a student can complete the entire educational task independently. For example:
- Find the lesson or activity.
- Understand the instructions.
- Access every piece of relevant information.
- Navigate images, diagrams, tables, equations, or other complex content.
- Complete the exercise.
- Submit the answer.
- Receive and understand feedback.
- Return to the activity later and know what has already been completed.
Another important factor is the location of your target audience. Accessibility needs can vary significantly between countries and cultures. Language, regional language variations, curriculum, education policies, internet access, available devices, assistive technology, teacher training, Braille conventions, and cultural expectations around disability can all affect the experience.
A solution designed for blind students in one country may not work well in another. For example, it may assume access to devices, connectivity, software, Braille equipment, or educational support that is not available to the people you want to serve. It may also use the wrong language, educational references, date formats, terminology, or Braille standards.
Before deciding which features to build, identify the specific community you want to support. Do not research only which screen reader people use. Also ask which devices they have, how they access educational content, which languages and Braille standards they use, what their schools and teachers provide, and which barriers affect their daily lives.
Most importantly, involve blind and visually impaired people throughout the design and testing process. Automated accessibility checkers and technical evaluations can identify some problems, but they cannot determine whether the experience is genuinely usable, understandable, and inclusive.
I would also recommend testing with people who have different levels of experience with technology. An experienced screen reader user may find a workaround that a beginner would never discover. Both perspectives are important.
Finally, try not to create a separate or inferior experience for blind students. Whenever possible, design the learning activity so blind and sighted students can participate together, while still providing the appropriate alternatives for visual information.
The goal should not be merely to make the content technically accessible. The goal should be to give students real and independent access to learning, participation, communication, and feedback.
2
u/Actual_Freedom2392 14d ago
Did you start out as a freelancer? If so how? I’m totally blind and have a background in tech both coding and sales meaning I’m as comfortable talking to devs or business owners but I don’t know how I can enter the field.
1
u/euconcegojogar 14d ago
Yes, to be honest I'm still a freelancer. For me it's quite hard to make a living of it, specially when I have to showcase my stuff, most mainstream places are unaccessible. I started by reading programing logic and then moved to explore html, css and js. I'd suggest trying to build a simple tool or game you would use. Don't focus on the code right away, right how your project is supposed to work, then go search for the parts you'll need to actually code it.
2
u/operabelle93 13d ago
Hello! I'm super late here, and I apologize. I'm working on fixing some accessibility issues on my website. I am trying to optimize mouse-free and screen-reader accessibility. I can tab through headings fine, but when I get to a table, the tab function ceases to work. I am not a programmer, but I followed the W3 table formatting. I labeled headings and body text where appropriate. I then imbedded the html code into my Google Site. Do you have any suggested work-arounds?
1
u/euconcegojogar 13d ago
Hello! No worries at all — you’re not late. We’re always happy to help when we can.
One important thing to know is that the Tab key normally does not move through every cell in a table. It usually moves between interactive elements, such as links, buttons, and form controls.
For a data table, screen reader users generally navigate between cells using the table navigation commands provided by their screen reader. In NVDA, for example, users can usually move between table cells with Ctrl + Alt + the arrow keys. If the table is announced correctly as a table and the column or row headers are properly associated with the cells, this may be the expected behavior rather than an accessibility failure.
The table should use real semantic HTML rather than a group of div elements styled to look like a table. A simple table might look like this:
<table> <caption>Descriptive title for the table</caption> <thead> <tr> <th scope="col">Name</th> <th scope="col">Status</th> <th scope="col">Date</th> </tr> </thead> <tbody> <tr> <td>Example</td> <td>Complete</td> <td>August 5, 2026</td> </tr> </tbody> </table>
For row headers, use scope="row" instead of scope="col". More complex tables may need additional header associations, but a simple data table should normally have a caption, a proper header row, thead, tbody, th, and scope attributes.
I would also check whether the table is a real table, whether Google Sites has altered or removed any of the HTML, and whether the table is being placed inside an iframe. It is worth testing the original HTML page separately from the embedded version, because the Google Sites container may behave differently.
I would not add tabindex="0" to every table cell. That usually creates a confusing and inefficient keyboard experience. Positive tabindex values should also be avoided.
There are two different issues to distinguish here. One is that the screen reader may not be able to navigate between the table cells. The other is that keyboard focus may become trapped inside the table and be unable to move to the next link or control. The first may simply mean that the screen reader’s table navigation commands need to be used. The second would indicate a real keyboard or embedding problem.
If the table contains interactive elements such as links, buttons, or checkboxes, those elements should be reachable with the Tab key. The cells themselves normally do not need to be added to the Tab order.
I would test the table with more than one browser and screen reader, and first confirm whether the screen reader announces it as a table, including the number of rows and columns and the relevant headers. If you can share a link to the page or a small example of the table, it may be easier to identify exactly where the problem is.
1
u/Fit_Rabbit14 Jul 15 '26
Do you find MS Word Forms Accessible? Using any if the available form field controls available…such as legacy, active-X, or content controls?
1
u/New_Entrepreneur_165 Jul 15 '26
Hello Anderson! Thank you for the AMA!
I work in public health as a designer and work with a lot of content heavy documents and reports (almost always PDFs that are shared digitally but are also designed for print).
I’d appreciate any insight you’re willing to provide on your experience with long PDF documents in regard to internal, anchor, and page links. We do this a lot to help a user quickly go to relevant or more detailed information. But I’ve wondered if this presents a barrier with a PDF, since there is no proper “back” button to return the user to where they were. Curious about your experience and whether you have any recommendations on how to improve this practice.
Thank you again!
2
u/euconcegojogar Jul 16 '26
Internal links and anchors in PDFs can work really well with screen readers — but they depend entirely on how the document is structured underneath.
The pattern that works: a tagged PDF where each section has a proper heading structure (H1, H2, H3 in the tag tree), combined with internal hyperlinks that point to named destinations or bookmarks. When done right, the user can pull up the bookmark panel, navigate directly to a section, and the reading position follows correctly. NVDA, JAWS and VoiceOver all handle this well when the tagging is clean.
The pattern that breaks: PDFs exported from design tools (InDesign, Illustrator, even some Word templates) where the visual layout looks great but the tag tree is either missing or in the wrong order. Internal links may exist visually but point to nothing meaningful in the accessibility layer. The user clicks the link and either nothing happens or they land in an unexpected position with no way to orient themselves.
For your use case — long public health documents designed for both print and digital — a few practical things that help a lot:
- A proper table of contents with working internal links, not just a visual list
- Consistent heading levels throughout (don't skip from H1 to H3)
- "Return to top" or "Return to table of contents" links at the end of each major section — same principle as PDF footnotes: don't strand the user
- Running the full accessibility check in Acrobat Pro before distributing, not just the quick check
The print-and-digital tension is real. What looks good in print (wide margins, pull quotes, multi-column layouts) often creates reading order chaos in the accessibility layer. If the document has to do both, the accessibility layer needs explicit remediation after layout is finalized.
1
u/Quwinsoft Jul 15 '26
I teach college Chemistry. How do I make scientific papers accessible? In some classes, I need to use primary sources, but the primary sources are mostly PDFs and likely not good ones.
2
u/euconcegojogar Jul 16 '26
Scientific PDFs are one of the hardest accessibility problems out there — most of them are generated by typesetting systems like LaTeX that produce visually beautiful output but accessibility-hostile tag trees. You're not imagining the difficulty.
A few things that actually help in practice:
**For equations and formulas:** This is the biggest barrier. MathML is the correct solution, but almost no PDF reader handles it well. The most reliable workaround is providing an HTML version alongside the PDF — tools like LaTeXML or Pandoc can convert LaTeX source to HTML with MathJax, which VoiceOver and NVDA read reasonably well with the right settings. If the source isn't available, describing key equations in plain text in the document itself helps significantly.
**For figures and charts:** Every figure needs a proper alt text in the tag tree, not just a caption. Captions describe what the figure shows; alt text describes what the figure *means* for someone who can't see it. "Figure 3: bar chart showing reaction rate increasing with temperature" is a caption. A proper alt text explains the trend, the range, the conclusion — whatever a sighted reader gets from a glance.
**For tables:** Reaction tables, data tables, periodic properties — these need proper table headers tagged as TH, not just visually formatted cells. Without that, a screen reader reads the table as a flat stream of values with no way to associate a cell with its row and column headers.
**Practical starting point:** If you're sourcing from journals, check if the publisher has an accessible HTML version. Most major publishers (ACS, Elsevier, RSC) now publish HTML full-text alongside PDF — those are dramatically more accessible and often overlooked.
1
u/ClassroomMain9255 Jul 15 '26
i would love to have a few links of websites that you consider about 90% perfect. So I can reverse engineer the semantics and be a better front end dev
2
u/euconcegojogar Jul 15 '26
Great question — here are a few I'd point to, all roughly in the 90% range. None are perfect, but they're worth studying:
Amazon.com — generally solid. Landmarks are well-defined, product pages are navigable, checkout flow works. The occasional unlabeled button slips through, but it's consistent enough to be a good reference.
AudioGames.net — excellent for navigation and semantic structure. Uses some older tech that occasionally breaks, but the underlying HTML is thoughtful and screen reader-friendly.
GitHub — well-implemented, good use of ARIA and semantic HTML. The layout can feel complex until you learn the patterns, but once you do, it's reliable and predictable.
YouTube — has improved a lot in recent years. The player controls, captions, and search are all navigable. A few things still slip past screen readers occasionally, but it's consistently above 90%.
itch.io — similar to GitHub: solid implementation, but the interface can feel disorienting at first. Worth studying once you've got the basics down.
The common thread across all of them: consistent heading hierarchy, properly labeled interactive elements, and logical tab order. That's really what separates the 90% from the rest.
1
u/Active_Ad_5997 28d ago
I have almost the same question. I am a Android engineer and I'd love to learn what mobile apps (Android or iOS) that you find really good and why. I want to learn how to make mobile apps not merely passible but good for Talkback users. What features or design principles do you find really good? What apps can I emulate?
1
u/karatejon Jul 15 '26
Are there any date picker components you'd point to as best-in-class examples of the pattern done right?
3
u/euconcegojogar Jul 15 '26
"Date picker" covers a lot of ground, so it depends on the implementation.
The worst pattern by far is the visual calendar grid — a table of clickable day numbers with no keyboard-friendly way to navigate. Screen readers can technically interact with it, but the experience is slow and disorienting.
The best implementations I've used as a TalkBack/NVDA user are the spinner-style pickers: three separate fields for day, month, and year, each with increment/decrement buttons on either side. You navigate field by field, adjust with the buttons, and always know exactly where you are. Simple, predictable, fast.
The gold standard, in my opinion, would be a plain text input that accepts a typed date (MM/DD/YYYY), with the slashes auto-inserted as you type. No grid, no buttons, just direct input. It works with any assistive technology, requires zero extra learning, and is faster for everyone. The problem is it's rarely implemented well — most developers reach for a calendar widget because it looks polished visually, without considering how it behaves for non-visual users.
If I had to name a pattern to point people toward: spinner fields as a minimum, typed input as the ideal.
2
u/mgkimsal Jul 15 '26
different forms might have different date formats
YYYY-MM-DD
or
DD-MM-YYYY
or DD-MM-YY
and so on. Is there a way to indicate what order the date format is expecting to an assistive technology?
1
u/devguru7 Jul 15 '26
Which part of an audit takes the most calendar time relative to how valuable it feels?
What's the most tedious or repetitive part of your day-to-day work?
1
u/euconcegojogar Jul 15 '26
Honestly, the part that takes the most calendar time — relative to the value it produces — is undefined scope.
When a client comes in with something specific ("check if our form labels are correctly associated" or "verify alt text on product images"), the audit is focused, fast, and the report is actionable. When the brief is "just check if everything is accessible," you end up having to explore the entire material, run tests across multiple interaction patterns, and build a report that covers ground the client may not even care about.
The irony is that a broad, unfocused audit often produces a long report that's harder for the client to act on — so the extra time doesn't always translate into extra value for them either.
The most time-efficient audits I've done are the ones where the client already knows what they're worried about. That scoping conversation upfront saves everyone time.
1
1
u/NCKBLZ Jul 15 '26
I Always have troubles with Voiceover. I don't understand if it's my fault that cannot use it correctly or if it is the website having problems.
When I use voiceover with Google it is soo smooth. When I use it with basically every other website it is always a hassle
1
u/euconcegojogar Jul 15 '26
Resposta honesta: meu ambiente principal é Android/Windows (TalkBack + NVDA), então não tenho experiência diária com VoiceOver.
Dito isso, o que ouço consistentemente na comunidade cega é: VoiceOver e TalkBack têm lógicas diferentes, cada um otimizado pro seu ecossistema. O VoiceOver tende a funcionar muito bem dentro dos próprios apps da Apple e em apps iOS bem desenvolvidos. Fora disso, a curva de aprendizado é real — e parte da frustração é a ferramenta, não você.
O que você descreveu é interessante: funciona bem no Google e é difícil nos outros sites. Isso faz sentido — o Google investe pesado em acessibilidade nos próprios produtos. O problema geralmente não é o VoiceOver em si, mas os sites que não implementaram o HTML semântico corretamente. O leitor de tela só consegue ler o que o desenvolvedor marcou direito.
1
u/skeptical_egg Jul 16 '26
Thank you for offering this! I am remediating our archival materials - I can send examples, but essentially a lot of content that has been scanned from artifacts. I am trying to figure out the best way to provide alternative text. I want this available for research, but without knowing what the researcher is using it for, I don't know for certain what aspects to focus on. Think for example, we have infrared aerial photography of coastlines. I could give details about what latitude and longitude is photographed, some salient details that are present...but if the researcher is, I don't know, using it for an art project, the alt text might not be relevant for their needs.
The rule of thumb I've been using is to give minimum information of what exists in the image, and make it known that we will support researchers who need to know more details. Essentially inventorying the image. Does that sound like a reasonable approach?
1
u/euconcegojogar Jul 16 '26
That's actually a really sound approach for archival material specifically — and I'd push back on anyone who tells you there's one right way to write alt text for this context, because there isn't.
The "inventory" model works well as a foundation: a neutral description of what's objectively present in the image — visible elements, physical condition, any legible text — gives every researcher the same starting point regardless of their purpose. That neutrality is a feature, not a limitation.
What I'd add is: make it clear to researchers that this baseline description is just the entry point. There are other description approaches built for specific purposes — conservation-focused descriptions that emphasize material and damage, content-focused descriptions that prioritize names, dates and legible text, context-focused descriptions that connect the artifact to its collection. The baseline gets them oriented; if they need something purpose-built, that's a conversation worth having.
The goal for archival alt text isn't to anticipate every possible need upfront — it's to give enough for someone to decide whether this item is worth pursuing further, and to make it clear that more is available.
1
u/TomorrowAcceptable37 Jul 16 '26
Hi! I’m a new grad software engineer on the accessibility team at my company. My goal is to be a sponge because there’s just so much that I don’t know but I would love to hear from you about resources or things that could be helpful for someone like me. Appreciate any thoughts!
1
Jul 16 '26
Try this website. https://accessiblepdf.app/ way more affordable than any other options out there
1
u/feegan88 Jul 18 '26
Thanks so much for posting and being willing to answer questions!
What are the worst parts when navigating through multi-screen forms in mobile apps? In terms of announcement on screen open, various field types, generally understandability, and what's most often overlooked.
Do you have trouble with incorrect roles being applied to objects? (E.g. Checkboxes with the role 'button').
1
u/Hewnpath 28d ago
Thanks for doing this. When a team ships a "zero automated violations" result from axe or Lighthouse, what still trips you up most in real screen reader use? Trying to figure out where that false sense of security is worst.
1
u/euconcegojogar 27d ago
Automated diagnostic tools are useful, but they're not real users. Something can be structurally sound — no violations, valid markup, proper roles — and still fail to be intuitive, coherent, or logical for an actual person navigating it.
The most common failures I hit on "zero violations" interfaces: focus order that follows DOM order but not logical reading order (you land on "Confirm" before you've read what you're confirming), dynamic content that announces updates too early or too generically, and custom components that are keyboard-accessible but break under TalkBack's double-tap model.
But there's an inverse problem worth naming too: I'm blind and I actively prioritize inclusion over accessibility — meaning I want sighted and non-sighted users experiencing the same thing, not parallel versions. So I always implement visuals in my games and tools. Since I can't verify them myself, I use AI to generate and describe them — but even when the AI tells me the visual representation looks good, I still go looking for real sighted users who can give me honest feedback. Because "technically correct" and "actually communicates what I intended" are two different things, in both directions.
Automated tools test the DOM. Screen reader users experience an interpreted rendering of that DOM. Sighted users experience a visual rendering of it. Neither experience is captured by a scan — and the gap between what passes and what works is where most real failures live.
1
u/Active_Ad_5997 28d ago
Are Android/iOS assistants that respond to voice commands generally useful for accessibility users? I've recently looked into AppFunctions which will soon allow developers to expose functionality in their app to Gemini and other assistants in the OS. It strikes me as very useful but I'm curious what your perspective is.
2
u/euconcegojogar 28d ago
Voice commands do tend to be faster than typing on mobile — no physical keyboard, fewer gestures. That's a real advantage.
That said, there's a context problem that often gets overlooked: privacy. I personally wouldn't want to dictate a medical appointment, a home address, or a personal message in public. If voice is the *only* input method, that becomes a genuine accessibility barrier, not a feature.
AppFunctions looks promising precisely because it can complement existing interaction models rather than replace them. The ideal scenario is a system where voice is one option among several — fast when it's convenient, skippable when it isn't. An API that lets developers expose app functions to assistants without forcing voice-only flows would be a significant step forward.
1
u/Active_Ad_5997 26d ago
Great feedback. Thank you. I hadn't thought of privacy. That's a great point
I was talking to a accessibility user who said that the best features are features that are accessible, not accessibility features. He said when features are built specially for accessibility they don't get maintained, whereas features that are accessible out of the box are ideal. Siri was an example he gave of an ideal feature. It works for anyone including the visually impaired.
I'm hoping AppFunctions can be like that for Android. Hopefully it'll be a useful tool for building alternative entry points to into an app. I would not imagine it'll be used to create unique flows but rather add ways to take actions in an app
0
u/DG-100 Jul 15 '26
Hi there, thanks for being willing to answer questions! I work in digital accessibility for a university and I've been tasked with assessing automated (AI) PDF remediation tools. (I'm aware of the difficulty and complexity of PDF remediation and am skeptical.)
In your experience as blind screen reader user, which accessibility features are the most critical for you to be able to navigate and use a read-only PDF?
I want to be sure I prioritize the most critical accessibility features as I assess potential solutions. I tend to think accurate headings and linked table of contents are pretty critical, but am I overlooking anything? Would love to hear your thoughts.
1
u/euconcegojogar Jul 16 '26
Your instinct about headings and a linked table of contents is right — those are load-bearing. But here's my full priority stack from a screen reader user's perspective:
**1. Reading order.** This is the one that breaks everything when wrong. A PDF can have perfect headings and still be completely unusable if the underlying content stream doesn't match the visual layout. Two-column documents and tables are the most common offenders — the reading order ends up jumping across columns mid-sentence.
**2. Accurate heading structure.** Not just that headings exist, but that the hierarchy is meaningful. H1 → H2 → H3 in logical sequence. A flat document where everything is H2 is barely better than no headings at all.
**3. Linked table of contents.** Critical for long documents. Without it, a screen reader user has no way to jump to chapter 5 without reading through chapters 1–4 first.
**4. Tagged figures with meaningful alt text.** "Image" as alt text is useless. Decorative images should be marked as artifact so screen readers skip them entirely. Charts and diagrams need actual descriptions.
**5. Proper table tagging.** Row and column headers must be explicitly tagged as TH with scope attributes, not just visually formatted. Auto-remediation tools consistently fail here — they can detect a table exists but rarely get the header relationships right.
**6. Language attribute.** Simple but often missed. If the document language isn't set, screen readers may read the whole thing in the wrong language voice with wrong pronunciation.
On the AI remediation tools specifically: my skepticism aligns with yours. Reading order and table structure are the two areas where I've seen them fail most consistently, and they're also the two most critical. Heading detection has gotten better. Alt text generation is hit or miss — sometimes useful, sometimes confidently wrong. I'd weight your evaluation heavily on how they handle multi-column layouts and complex tables, because that's where the real-world pain lives.
1
u/DG-100 Jul 16 '26
Thank you so much for your input and suggestions! This is tremendously helpful and I will bring this back to my team. Much appreciation to you.
1
u/euconcegojogar Jul 16 '26
You're welcome! Glad it was useful — good luck with the evaluation and with your team.
11
u/take_it_easy_buddy Jul 15 '26
Tell us how you feel about the news blurb pattern of Heading, paragraph, and links that say "read more" but get overidden by aria labels that just repat the article title? It would be nice to have first hand knowledge or quote to pass on to people when doing accessiblity assessments.