Eric Eggert
Alda Vigdís@yatil Oh yes. Another reason for why implementing separate hidden "accessible" elements from the visually represented ones is not very smart.
Eskild Hustvedt@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.
FeralRobots@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.