Screen readers are not testing tools · Eric Eggert

Testing with assistive technologies is an important part of any accessibility review. However, especially when auditing against the Web …

Eric Eggert
The initial stub for this article was written in 2024.
@yatil thanks for giving me something to link to when people ask for a screen reader emulator 🙏
@Kilian At your service! 🫡
@FreakyFwoof @yatil Once I was requesting use of JFW in a company and they didn't understand why I needed it as I wasn't a web developer. This actually did happen. Won't name and shame.
@yatil Oh yes. Another reason for why implementing separate hidden "accessible" elements from the visually represented ones is not very smart.
@alda @yatil Does that apply to ‘hidden’ descriptions (that don’t 1:1 match visuals) as well? I make an app, iOS/Android/Linux. In it some data is in a table, which makes sense when seen, but that was awkward when using a screen reader, so I excluded the table from the accessobility tree, and added lines of description, one per row, instead, that added the context of the column headers. So instead of it reading (header) «Medication» «Taken» (content row 1) «Imigran» «16:03» (row 2) «Cataflam» «16:03», it instead skips the header row, and resds «Imigran taken at 16:03» and «Cataflam taken at 16:03» etc.

@zerodogg @alda I mean, that’s barely a table. I would probably just use a list and use CSS (no idea about native) for visuals. The “taken at” is imho clear from the context and just eats up time.

I don’t know how you navigated the table, there is specific interactions to navigate them. But here you don’t have something to compare, so there is little benefit of the table structure.

@yatil @alda App, not web. Flutter to be exact. So CSS is off the table, so to speak. Screen reader insisted on navigating it cell by cell.
@zerodogg @alda Yeah, Flutter is generally problematic from what I hear, but as written above, I have little knowledge about best practices in native app development.
@yatil @alda Nod. It’s a FOSS app, so I’m mostly basing it on what felt natural, though I might have stepped in the «non-user of screenreaders» trap you mentioned. That table felt off to me, so I labelled it instead.
@yatil @zerodogg
Yeah it's a bit of a tangent but when I teach about table accessibility in word processors I often counsel people to consider implementing 2-column tables as unordered lists. It seems like it should be a lot less noisy.
@alda
@FeralRobots @zerodogg @alda My general rule is: do you expect users to compare data across rows and columns? If not, with few columns, a list is probably the simpler variant. (And in word processors, use tab stops to align the text, it can even right align prices, for example.)
@yatil @FeralRobots @alda Nod, to the screen reader it is essentially an unordered list, navigated one line at a time. But visually it's a two column table. There's no need to compare, really, it's just a display for user data.
@yatil This is very helpful. We’re still maturing our accessibility practices, I need to send this to our QA folks.
@yatil Thank youuuuuu!