Please don’t kill the messenger! When I audit accessibility of native mobile apps, I often stumble on this problem and I decided to write it down.
Short story – lists like we know and love them in documents and on the web (web documents and apps) do not exist on native mobile apps. Well, at least not on iOS. Sure, if you use web view you can still have them and they work, but on native “native” iOS you will not find a semantic list for content like you are used to see on the web.
This is most certainly also the reason for frameworks like React Native to lack semantics for lists. Because they can not really fake it…
But there is List in iOS
But, Bogdan, iOS does offer List components, you may say.
Indeed it does, but it is not meant for content in the same way as we use <ul> and <ol>. If you have seen iOS Settings – that is the List they are kind of referring to.
many apps use lists to express an overall information hierarchy and help people navigate it
Apple Human Interface Guidelines on lists and tables (opens in new window).
So basically – List is not quite just a list. It is way more and it is designed to be like that on purpose. We may disagree, but it is a fact. We may, in theory, use List to make a old school list, but to my knowledge we can not style it to be seen as a part of the content – we can not make it look and feel like the one on the web.
What about FlatList and SectionList in React Native?
Well, theoretically they seem appropriate. Until you check them with accessibility tools and assistive technology.
Both FlatList and SectionList bear a promise of semantics at first sight, but lack it when I tested them with VoiceOver (at the time of writing this post at least).
Unfortunately the SectionList includes also headings that are not announced as headings, so I must strongly advise against using it at the moment.
Faking a list is dangerous
Once again you can quickly argue that we can always use VStack and nest HStack, or make a loop with output, and just make a list like that looks identical to <ul> and <ol>.
Sure, you can fake it with different technologies, overriding visual content, adding visual bullets and style it as a list, but you can and probably will introduce accessibility issues by doing so. The behavior with assistive technologies will be broken. And you will most probably make an unequal experience for people that can see the screen and people that use a screen reader.
Info and relationships
Faking a list visually can work, but then we need to convey information, structure and relationships in text. I will deliberately not provide any examples here, because this is a typical “it depends” scenario.
Just some clues, in a list:
- Is the order of items meaningless or is it vital to have the items in order?
- List size is always important in my book, but is it really in your case?
- Are we perhaps nesting lists in lists?
So, in theory, we can fake a list and describe it with text. But I am quite confident that the user interface design plan was just a list originally (probably copied from a webpage or document).
What to do with lists on native apps then?
On Android – you have much more freedom (please check List and item information (opens in new window)).
But on iOS – this is the time for the famous it depends, sorry. Sometimes we can fake them and make them individually focusable, sometimes we add a heading, for example “12 favorite products” before such a list.
The problem is position in set, especially when it is vital info. Perhaps having it in text works then.
When we (try to) operate across platforms, we can now quickly recognize that even if we can re-use the same content for documents, web and Android, we get into trouble with iOS in this case.
Personally I find it almost impossible to understand the decision made to not have a semantic list for content, like we have on the web, but we need to make our best to make things work for people.
Native mobile apps are obviously not web (for better and worse) and we need to design for them specifically for best usability and accessibility by understanding the platform.
Even better – co-design with people with disabilities and accessibility specialists.
