ios-swiftui-accessibility-techniques
ios-swiftui-accessibility-techniques copied to clipboard
cvs-health
Accessibility Hints on Data Table rows
The data tables documentation is awesome! The only thing I hesitate on is the use of an .accessibilityHint to convey row/column information. The only reason I say that is because there are still users who choose to have hints turned off.
The feedback I have gotten from VoiceOver users is to include the association of header and row within the label for each item. That way whether hints are turn on/off it is conveyed. Now this does cause other potential issues such as overriding the text of the item in the cell or labels being super long.
Just as a note, I do not condone having the label say "Row
Thanks for the feedback! I also used to recommend modifying the .accessibilityLabel to prepend the row and column header text to the cell but then I was thinking the VoiceOver user may not want to hear a long row and column header text always spoken before the cell text and they may prefer to hear the data cell text first and then the long row and column header text second. There's definitely no prescribed approach to take here since there are no native iOS data table semantics like th, td, or caption, for table in HTML.
I've updated the docs and the swift file to include using both techniques either hint or label. This would be a good usability test with VoiceOver users.
.accessibilityHint VoiceOver says "$30, 90 Day, CLONIDINE 0.1mg"
.accessibilityLabel VoiceOver says "90 Day, CLONIDINE 0.1 mg, $30"
The updated example is waiting approval in the App Store now should be out fast https://apps.apple.com/us/app/swiftui-accessibility-techs/id6474141089
I agree 100% with you that this would be a great usability test with real users to see what the preference is!
The consistent feedback I have gotten is labels including the info. However, we have gotten a range of feedback that goes from hints, to it not announcing EXACTLY as web. It is one of those things where I think there is no middle ground in a lot of apps currently, it is is either not announcing an association OR mobile teams are trying to openly mimic web. (bleh)
Either way the update you got will drastically help improve data tables in mobile apps since there isn't a load of guidance out there!
I could not find a single page with guidance on building accessible data tables for mobile apps.
What about using accessibilityValue to communicate a cell's row/column header information? I personally think this modifier has great potential to expose non-label information in a way that is more robust than relying on accessibilityHint.
What about using accessibilityValue to communicate a cell's row/column header information? I personally think this modifier has great potential to expose non-label information in a way that is more robust than relying on accessibilityHint.
Thanks for the feedback! I can update the page with an additional good example showing the row and column header text in the a11yValue.
I've updated the technique and doc with a11yValue. Will get it into the App Store soon.
@pauljadam Great to have discovered your app. I will spend a lot of time with it!
As to the table examples: What I find confusing is that when vocusing the tables with VoiceOver with the rotor on container, there is no announcement that now I am focussing a table (so it would be good if it said "generic price list" and then "table") - and the next horizontal swipe will skip table contents and land on Details. I can get to the first column heading, "name", only by vertically swiping up (which might be fine if the element's role, or a hint, made me aware of that change of mode) - and from then on, horizontal swiping will traverse all table elements in sequential fashion and properly output the headers when focussing cells (as coded). Maybe this is the expected behaviour that VO users will recognize - but having said that, tables are quite rare in the app world so I wouldn't count on such prior knowledge.
I have checked 'tables' in my rotor settings, but no table role is announced - maybe it is not implemented in SwiftUI? Maybe this is just applicable to HTML tables in webviews? if the accessiblity role table could be allocated, it would seem helpful even if these are not a 'real' tables.
In that respect (getting to the table data), the bad example is actually easier than the best practice ones: after the heading "Bad Example", the horizontal swipe focus lands on the first column header, and traversing all three headers gives an idea that here are three columns. Running through the next rows which then output name of the drug / price one / price two respectively, this might actually be understood sequentially without repeating the column headers on each cell - at least with a structure as simple as in this data table. Certainly output a lot less verbose than the recommended examples. Could it be that it is really down to the complexity of table content what should be considered best practice?
I also have some concerns whether the recommendation to basically embed relevant header info in each and every cell via one of the techniques described is something developers will actually do at scale, and get right. It seems so much more onerous compared to HTML semantics.
@detlevhfischer There is no table trait or role that can be added to the table like a heading trait and no ability to skip between tables like you can with headings. <table> semantics and navigation only work on HTML web views.
The good example tables are designed to speak the row and column header text even during direct touch exploration or swiping backwards, you don't have to swipe it in the perfect linear order to know the row and column headers in the good examples.
The idea of appending the row and column header text to the cell is the same idea as appending visible error message text or input instruction text to a form input. Native apps have no aria-describedby or data table semantics so you have to hack that information onto the inputs or cells manually.
@pauladam Thanks for the explanation. Maybe something changed / improved with iOS 16? This video talks about SwiftUI and tables on iOS but doesn't say much about what would be exposed to the screen reader. I have contacted Karin Prater and hope she can chime in.
@detlevhfischer I've added a new Platform Defect Example to the Data Tables page showing the native Table() element that works on iPad or macOS only and it does speak the column headers as expected but not the row headers.
The platform defect example uses a native
Table()element which does speak its column header text to VoiceOver when moving between columns but does not speak its row header text when moving between rows.Table()elements support iPad or macOS only. On iPhone only the first column of data cells in aTable()will display.