Display horizontally-scrolling categories in a browse group

ggeisler commented 3 years ago

Related to #1066 (preliminary discussion) and #1145 (widget for this feature).

The general idea is to present the published browse categories associated with a published browse group in a row on the page. On desktop viewports, three browse categories are shown at one time, with previous/next controls available for scrolling, where scrolling is done by groups of three (except at either end of the list, if there are less than three left), rather than one at a time as is done in some similar components.

I leave it to the developers to decide on the best component/library to base this on, but I’ll note that:

Bootstrap doesn’t seem to have a native component that clearly matches this. The Carousel component has the scrolling effect but is more like a single-item slideshow.
There are some third-party Bootstrap-based examples that are roughly similar: https://codepen.io/davidbiek/pen/bMrQKN.
Not Bootstrap-based, but the Slick library looks well-done and has lots of options, some of which approximate what we want to do: http://kenwheeler.github.io/slick/

A & B: Heading and associated link

Browse group heading: H2 with font-size: 1.875rem;
Both heading and link are font-weight: normal; and default font-color (probably don’t need to explicitly set those)
View all link is $font-size-base (1.25rem)
View all link styled with text-decoration: underline; for all states (we don’t use underline for links in the normal state elsewhere on the site right now, but I think it’s really important that we make these clear links to standout from the group title text)
There should be ~20px horizontal padding between the group heading and View all link

C: Previous/Next buttons

Note that by including both previous and next buttons I’m suggesting that we not have the navigation of the categories wrap. When you get to the last set of categories in a group, the next button is disabled and you have to use the previous button to go back and see the other sets of categories in the group.

SVG icon source: https://fontawesome.com/icons/arrow-alt-circle-right?style=solid and https://fontawesome.com/icons/arrow-alt-circle-left?style=solid
Alignment: right-aligned with edge of content area (centered in the content area for XS and SM viewports as discussed later)
Spacing: 1rem between icons
Size: 32x32 on desktop; 44x44 on MD and smaller viewports (looks big but that’s the recommended minimum size for primary controls when touch is involved, so let’s try it?)
Active button color: #707070 (suggest adding new variable $color-black-lighter: #707070;)
Disabled button color: $color-gray-medium (#ccc)

Vertical spacing between rows

3rem between rows (split between 1.5rem top and bottom, I think, unless this doesn’t seem to work very well. I can do some fine-tuning of spacing later, if necessary)

D: Responsive adjustments

The design assumes the browse category blocks will use the exact same sizing and other styling, including the text labels on the blocks, as the browse categories/pages widgets currently do. Because of that I won’t include any sizing details here other than to note that the XS viewport uses one size (the largest), MD and LG use another, XL a third size.

The SM viewport uses a fourth size, which is pretty small. This could be problematic in DLME because we’re using the extra caption line for at least the time period categories and I’m doubtful that all of the time period labels will fit on the SM sized block. So at least for a first-pass, perhaps we should diverge from the browse category/pages widget styling for the SM viewport only, and go with the same styling there as the XS styling.

Longer-term, or if it is feasible to do in the first-pass at this, I think the SM viewport might work well with a 2-up version of the horizontally-scrolling widget. (I can mock that up later to be sure and suggest exact sizing details.)

XS and SM viewport deviations

Although most of the sizing and styling can follow the pattern of the browse categories/pages widgets, there are a few deviations for the XS and SM viewports we need to make:

A: In the both the XS and SM viewports, go with a 1-up display (at SM the current browse categories widget uses a 3-up display); to see the other blocks in that group the user needs to use the previous/next controls.
B & C: In both the XS and SM viewports, make the “View all” link right-aligned and move the previous/next buttons to a row below the group title/View all link, and center the buttons

XS viewport example

Keyboard/screenreader concerns

Below is a preliminary suggestion for dealing with accessibility concerns. I don’t want to delay this ticket while I take the time to understand all the relevant details and possibilities, but I can work with @camillevilla (to leverage her a11y knowledge) and/or whoever else works on this to resolve details around accessibility. For now:

We should add skip links to the start of each browse group row. The skip link is only visible on keyboard focus. It should enable the keyboard user to jump to the next browse group row without having to tab through any of the elements of the row they aren’t interested in.
The previous and next buttons, although they are definitely interactive elements, should not be keyboard accessible. The keyboard user who tabs into a browse group row (i.e., doesn’t select the skip link for the row) first lands on the “View all” link, then browse category block 1, browse category block 2, etc., continuing through all the category blocks.

The strategy above basically avoids a potentially confusing and tedious keyboard navigation sequence but does require the keyboard user to do more navigation if they choose to enter a browse group row. But they also have an easy way to bypass the browse group row entirely.

I think a similar strategy will work for the screenreader user; but that user will already have the headings to use to move over a given browse group row. So for both keyboard and screenreaders, I think the basic strategy is to hide the previous and next buttons and present all categories in a given browse group as a full set. I know there are more details to work out, but I hope that's enough to get started on this ticket.

Here’s a blog post that has some rationale for this strategy: https://medium.com/@lsnrae/if-you-must-use-a-carousel-make-it-accessible-977afd0173f4

RTL concerns

I can’t think of any special RTL considerations. It seems like everything should just flip as usual with RTL, such that the next arrow will point left and the blocks will slide from RTL instead of LTR.