We are designing a responsive (ok, maybe partly adaptive…) website for TfNSW to display Projects and Programs. They have a very heavy mobile user base, so we are exploring adding some native app conventions into the mobile version of the website rather than simple breakpoints.
We are liking the idea of using horizontal scrolls for blocks of content (like filters and some search results), but with vertical scrolling for the main content. Much like Google search results, UberEats, Deliveroo, multiple shopping apps, etc. These elements would not horizontally scroll on desktop. (See the red boxes for horizontal scroll in attached pic.)
My big question is if mixing scrolling like this would pass WCAG 2.1AA? It appears that we’d be compliant if we ensured:
Focus rings and highlights are displayed (Guideline 1.3)
Orientation works in both portrait and landscape modes (Guideline 1.3.4)
The text scales up to 200% without breaking the layout (Reflow Guideline 1.4.10)
The rows scroll and reorient to selection and focus via a keyboard or input action (Guideline 1.8)
We make sure the content can be tabbed through via keyboard or input action (Guideline 2.1)
There are hints that more content is available via a swipe
Content is kept in the linear flow from top to bottom, left to right, for sequential navigation (Guideline 2.2)
Content can be clicked / tapped / activated for direct navigation (Guideline 2.3)
But, I can’t find clear guidance on including both horizontal and vertical for mobile specific implementations. Does anyone here know or has anyone implemented something similar in the past?
Great question! I think there’s 2 parts to this, UI and UX.
To briefly cover how our cards work in a UX sense, there are 2 types of cards:
UI Cards - this is where ‘card’ refers to how it’s viewed on a screen (a self-contained box of content)
Hypertext cards - this is the pattern we’re talking about with the programs section above, where one screen of information is presented at a time
Our cards are usually used as a UI and this hasn’t come up yet, so we can start with the basics and, if needed, add some info to our pattern guidance for cards.
In it’s simplest form, the questions of a new pattern (albeit an existing component) are along these lines:
Is there a user need?
Does it match the visual look and feel?
Is it accessible?
Is there an existing approach, and has it been tested?
What examples of this already exist? Are they contextually the same for UX, or just the UI?
For this context, Search Results, there’s a pretty well established pattern, so before the UI work goes ahead, it might be worth validating there’s a problem with the very pedestrian (but amazingly usable!) list style that users, and screen readers, are familiar with.
The examples you gave are interesting. On the home screen from UberEats and Deliveroo there is a vertical scroll with nested horizontal scrolls - this looks to me like the pattern of a table where somebody looks for information along a single axis first, then goes deeper within it. On both UberEats and Deliveroo the pattern for search results is a single direction scroll.
Google search results has an interstitial step before the results, which has horizontal scrolling cards for a different results type, which seems to be based on it’s perception of what content type the user wanted. One thing to note here is that the section shows content that would not have come up in the regular search results because it’s a different content type entirely - it’s almost like a redirect for users who were searching in the wrong place.
As for WCAG-specific questions, @anna.yeshtukova might have some advice, she’s our in-house accessibility expert!
@amy.howard is working on a page template for search results which she may be able to share.
As for the functional aspect, I think your list of WCAG considerations has excellent coverage. Your focus rings will cover 1.3.3, and the application of 1.3.1 (the IA part of the same WCAG guideline) will fall to your content people, but that’s part of governance which isn’t always predictable at this stage!
I’ll let @anna.yeshtukova jump in if there’s anything functional being missed, but it sounds pretty well covered to me. I’d be interested to hear any insights about this from your testing to include some do/dont advice in the DDS for others doing the same in future.
Oh heeeeey @amy.howard and @anna.yeshtukova, I’m joining the party a little late as I was on leave last week. I work closely with Brian and am the AD on the Transport account in improving the UX across the site. I look forward to working with you guys on this awesome project. Cheers Russ
As TJ mentioned we’re in the early stages of looking at search and listing pages too which I can share with you. I’ve attached what we have so far, still a work in progress though.
It uses a simple list view to allow more results to be seen at a time and highlight key information for quick scanning. Where additional filtering options are required, filters are placed in one location so none are missed and give maximum control to the user. On smaller screens, filters are displayed in a separate view for a more focused experience and to create a clean layout for both filtering fields and result listings.
Very interesting ! Thanks for sharing the designs @amy.howard . We have had similar requirements around listing and search pages (and also recall little back and forth in terms of UX). This is a search page that we finally ended up with Global site search | Asbestos and a listing page SVPA | Planning Portal - Department of Planning and Environment . Although the listing page doesn’t fully comply (i think) with DDS but it is inspired by and uses many components directly.
Hey @amy.howard, thanks for posting your examples! Before you posted these, we had redesigned the site to make things more simple. Looks like we are tracking pretty similar to what you have mocked up on each row. For our site, we are looking to implement an elastic autocomplete search which should ideally allow customers to immediately go to the project page rather than going to search results first. But we are keeping the search results page for more complex searches or for results that don’t directly match a project.
On our results page, we rolled filters and sort into dropdown menus as we don’t expect them to be used as often, and we wanted to include a map. When someone hovers over each result, it highlights each pin (on desktop at least). Just a little different execution given we are showing results that are more location based rather than simple content based.
We’ll be doing user testing on these soon, so we should get some good feedback we can share!!
Looking good @brian_helium! Have you got a map solution in mind? We’re in the middle of putting something together, will be sharing more in the next couple of weeks!
Thanks for sharing and looking great @brian_helium and @Amit! Definitely looks like we’re all tracking very similar and great to see it adapted to different content types and user needs. Any feedback you get from User Testing we’d love to hear, as TJ mentioned we’re starting to look at maps as well so very keen to hear your insights!
We haven’t gotten to the point of deciding on a map solution, yet. We’ve been starting to explore OpenStreet Maps, Mapbox, and leaflet.js. It might depend on which will be easiest to display multiple pins, geo shapes/areas, and other data easily while still meeting WCAG. Also, how much each would cost given the higher number of requests and API calls we’ll need to do.
Transportnsw.info is using Mapbox for the trip planner, so having one solution for the entire organisation is also something that we’re considering. Or we might be able to use (or extend) that existing license.
We haven’t ruled out Google Maps, but due to cost it isn’t our forerunner.
