OK ARIA! Role=feed is here & it’s not ready for prime time
It was a day of nightmares; it was a day of darkness in my digital world. I felt this as my fingers and the tab key of my keyboard were in a war with the ever-scrolling content in a shopping site.
My head was about to explode into pieces, taking along with it the piccells of the monitor as we were captured within the walls of perennially scrolling popular products and then I realized that I would use my mouse as a bombshell to escape this invasion.
This was what I read on a power user’s wall. I felt I was trapped in myself as I just got a development requirement to implement an accessible infinite scrolling content in our site. I thought ARIA was there as a panacea. But this power had created a never ending cluster of questions and I was left in utter confusion.
When WAI-ARIA 1.1 came out I was excited because it brought a set of new roles, states & properties while deprecating few. These new set of additions will enable the developers to find a way around most complex problems while fixing dynamic widgets. We will be talking today about one of the Roles that got added to ARIA authoring practice & will bring new possibilities in browsing content for screen reader technology users. I am talking about none other than Role=feed… if you haven’t heard or read the specification then I suggest you go through the role=feed specification once.
In short role=feed makes infinite scroll accessible for the screen reader users. If you are wondering what is infinite scroll then here is a small definition about it.
Infinite scrolling is a web-design technique that loads content continuously as the user scrolls down the page, eliminating the need for pagination. The success of infinite scrolling on social media sites such as Twitter have made this technique popular, but that doesn’t mean you should do it too.
Source: Infinite Scrolling is Not for Every Website
What’s wrong here?
So infinite scroll helps us avoid pagination & users can keep on scrolling our content without clicking another link. See how much this is beneficial, marketing & design teams jumped on this technique immediately when this design pattern came into existence. Infinite scroll was not just on twitter & facebook, it rapidly moved to content rich sites like news portals, blogs & ecommerce stores. Depending on whom you ask you will hear different answers with regard to the success of infinite scroll on a particular App or website.
Infinite scroll was & is not accessible to a wide variety of userswith disabilities even today & we will be discussing few of them in this blog post. While role=feed makes infinite scroll accessible for screen reader users it left a number of user groups behind.
- Keyboard: keyboard only users cannot access the content inside the feed, when tabbed from element to another element focus moves from the last element of the ffeed that is currently visible on the screen to next element in the DOM order.
- Speech Recognition: users who use Dragon naturally or any other speech recognition software are totally left out of the infinite scroll experience.
- Screen readers” while infinite scroll becomes accessible to screen reader users in browse/reading mode it needs a bit of experience to identify these widgets. Some screen rreader users might think the page is very long & also might miss the complementary/footer region completely.
- Users who use a switch device: Just think of users who use a switch control to browse the web, the amount of stress they might have to go through if they are forced to use infinite scroll to access a particular content. Is there an easy way to navigate the infinite scroll for these user group?
- People with various motor impairments: Ok!lets assume that a person with a motor disability browsed through a set of content in the infinite scroll & found what the user is looking for. While the user is interacting with content if there is a twitch or a tremorwhile the finger is on the mouse wheel the content will move & it will bbe a time consuming task to find the same content again.
- Low vision users: users who have low vision tend to use a screen readers, screen magnification software or windows high contrast mode. Just imagine how easy it will be for a low vision user to access your content wrapped inside an infinite scroll? Being a low vision user a long time ago I can say with little certainly that it is impossible for me to use infinite scroll because as a low vision person I tend to use mouse with screen magnification. My hand & eye are in continuous coordination all the time & since my screen is magnified upto 6x times it was a continuous stress on my eye to find the right content . just imagine if I have to scroll couple of time to find the right content inside a infinite scroll… it will be very stressful on my eyes & my cognitive ability too.
- Cognitive users: There are various cognitive user groups like Dislexia, ADHD, Short termmemory loss etc & the only problem I see is that we tend to think vvery less about them before working on a design pattern. I am not sure what all problems they might face specifically about content inside a infinite scroll but rest assured that these user groups will have a say in it if you ask them about this design pattern.
- Able body users: yes yes… why tjust talk about people with disabilities when it comes to this design pattern… I have personally seen able body people struggling to understand & use infinite scroll… the assumption that all my users are able bodies & they will know how to use my new design pattern is a myth. So before you implement the design pattern work on your user stories & do some usability studies. You can read more on why infinite scroll is bad here
Short-fall of Role=”feed”
Now that we discussed few pitfalls of infinite scroll let’s also the address of building a design pattern for an infinite scroll that can address most or all of the user group needs.
The role=feed specification just address the needs of screen reader users who browse the web in browse/reading mode of the screen reader. And the design pattern “Feed Example by WAI-ARIA Authoring Practices” does not yet have ARIA Practices Task Force consensus. But this is not stopping businesses from adopting the usage of role=feed on the infinite scroll & they are not aware that a lot of user-groups are still left out who can cause legal trouble with regard to the inaccessibility of content.
The ARIA specification & design pattern needs bit of evolving with regard to role=feed & must cover most of the user groups to avoid any law suit if a APP or website decides to take the path of implementing infinite scroll.
Re-imagining infinite Scroll
If I have to reimagine & design a infinite scroll that will help all the user-groups that we discussed above then I would follow this design pattern,
- Put a switch control that a user can toggle on/off the infinite scroll even before interacting with infinite scroll content.
- Ideally the switch control can be placed before the role=feed & can be made visible when it receives keyboard focus.
- load more or pagination links must appear once the infinite scroll is switched-off so that user has the luxury of navigating the content at leasure.
The design pattern discussed above might not be perfect but it would be a great start to include the user groups that are left behind & with time it will evolve with web.
Embrace of technological innovations for business sake is not evil. But while doing so, we need to pause and think whether such innovations are paving way for everyone to access our business solutions. In this journey, it is not only the ARIA working group, or the designers or just the leaders who would drive the inclusive digital business experience. But it is a cross-functional work that has to again and again reinforce that one size doesn’t fit all. Infinite Scrolling is one such innovation which with right mixture of rethinking and empathetic redesign would propel more digital innovation and inclusivity.