I have read another closed thread about the fact a user cannot reach the footer due to the infinite scroll feature. It wasn’t resolved. Concerns were raised about it being a UX issue - which it most certainly is. But it has been brought to my attention because it is an Accessibility issue.
The issue:
Although the user is giving input i.e. scrolling they are not necessarily intending to activate the infinite scroll, instead the intention may be to reach the footer for additional information or support.
Any community using this setup will not pass level A of the WCAG 2.1.
Level A is considered to be the most basic and essential level of web accessibility.
I have been auditing a community and would class this issue a failure of success criteria:
2.2.2 Pause, Stop, Hide (Level A) Critical
For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
3.2.5 Change on Request (Level AAA) Serious
Changes of context are initiated only by user request or a mechanism is available to turn off such changes.
The solution:
Add a ‘load more posts’ button to the feed to give back the users control.
Allow users to choose how many posts to view at a time so that those seeking a more infinite experience can do so.
It’s not really acceptable to say “if you don’t like this setup choose another” - this one can easily be made more useable and should be. It is a moral and legal requirement for a lot of our clients.
Hopefully this helps make the case for the changes required.
Okay, so currently combining an infinite feed and footer creates an inaccessible solution.
But that doesn’t have to be the answer. Controls could be placed on the feed to give the user choice between loading more posts or reaching the footer. Is there any scope for this?
A footer is a really common web pattern. Making consistent, recognisable web experiences is a core principle in creating usable and understandable experiences.
Footers support Success Criteria (SC): 2.4.5 Multiple Ways (AA)
More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.
Not having footers turned off on specific pages supports SC 3.2.3 Consistent Navigation (AA)
Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.
Is it Discourse’s stance that if you choose that combination it’s your issue?
Do you know if any advice around this is provided in documentation somewhere that states this fact: “as adding a footer on a infinite scrolling website would render it inaccessible”?
I’m in a tricky position, I will have to suggest redesigns for some big communities we’re running. So just working out the full picture of this issue.
I’m not familiar with existing studies on this area, but it’s certainly a well-know fact that your shouldn’t put a footer on your infinite scrolling website. There are many popular examples here, Facebook, Twitter, Linkedin, Instagram, GMail, etc. None of those have footers, and all the web application functionality is available as they are used by billions.
That is not in our roadmap, and I’m not aware of any of our existing paying customers asking for something like this.
So, if I got the whole history right, your problem is that:
Your main property website has a footer
You want your main property and your Discourse instance to look familiar
Discourse won’t have a pro-eminent footer on some pages, as they infinite scroll the footer away.
You don’t want to have the footer on just some pages
I understand that it’s a complicated position, but being stoic about it you have only two options if you want to use Discourse:
Put the footer.
Use a page without infinite scrolling as the home page, like Categories - Discourse Meta, so it is featured prominently and don’t fret about it being out of reach in the /latest route.
Don’t put the footer.
Our discourse.org page has a footer, and so does our blog. But we don’t have the same footer here. Many companies do the same, and doing the opposite may be just trying to fit a square peg in a round hole.
I am representing a selection of your existing paying customers. Also as I mentioned in my initial post there are other threads discussing this combination and concern which have been dismissed in a similar manner to your recent response.
It is not my personal problem. It is an accessibility failure many communities are experiencing I was hoping the team would be open to fixing.
We will continue to use Discourse and look at building some of our own custom solutions as this is so far off your roadmap.
At the risk of being a bit partisan, I don’t think it’s entirely fair to classify Discourse as a web page?
It is a web app and as such blurs the line between web pages and apps.
If I approach it as an app that surely changes things significantly?
Open it as a PWA and it appears fairly convincingly to behave like an app.
If I open iOS Mail where is the footer?
(Ok, ok there are some basic controls on a bottom floating panel but that’s also true for Discourse in hub mode)
Is Apple being harangued for not having one?
What about Gmail?
How is ok for Gmail and Mail to have infinite scroll for emails, but it’s somehow not ok where Topic Lists are concerned? Aren’t they semantically very similar?
Would users be delighted if Gmail or iOS Mail devs were to introduce a button for more emails?
How come their accessibility experts have concluded that infinite scroll is ok for those two apps?
So are these guidelines even applicable in this case?
The forum at https://thepavilion.io/ has an extra footer you could use for inspiration. It works well on iOS Safari and less well (or at least differently) on the iOS Discourse app.