E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: Dan Smith
Date: Thu, Nov 19 2020 6:31PM
Subject: Card UX: Wrapping cards in an unordered list and Nesting when using anchor elements
No previous message | Next message →

Hi everyone,

I'm updating a card-based User Interface and would like your opinions (and
associated justifications) on the following:

1. Wrapping cards in an unordered list - When a grid of cards is
displayed on the page (as the listed results of a filter search), are there
known issues with making each card a list item (within an unordered list)?
2. Nesting when using anchor elements - When a card title is linked,
should the anchor/link element wrap the heading element, or should the
link/anchor element wrap the heading element?

If you're unfamiliar with what the card pattern is and what a card can
contain, please refer to the Rules on the BBC's GEL (Global Experience
Language) page about the Card pattern (
https://www.bbc.co.uk/gel/guidelines/cards#rules).


1. Wrapping cards in an unordered list

This was raised in a partial accessibility audit done by a 3rd party. I
think the implication was that a wrapping list interferes with the
semantics or exposing of child elements.

I haven't experienced any issues in my testing, so I wondered if this only
affects specific screen reader / browser combinations, or user interaction
patterns.

Have you experienced any side-effects from wrapping an unordered list
around card child elements like headings and images?


2. Nesting when using anchor elements

Historically, I would nest the anchor element inside the heading, as in
HTML4.01 the heading is a block element and the anchor was an inline
element.

However in HTML5 it's also valid for the link to wrap the heading, and WCAG
2.1 agrees (Example 7 on
https://www.w3.org/WAI/WCAG21/Techniques/html/H30.html).

My main concern here is that a colleague has raised the issue that the link
may not be discoverable with some user interaction patterns.

For example, in "Accessibility and Testing with VoiceOver OS (Mac)" (
https://bbc.github.io/accessibility-news-and-you/accessibility-and-testing-with-voiceover-os.html),
the BBC suggest developers to "use ‘VO + Right arrow' to read through each
element in the feature" (in VoiceOver).

When this interaction pattern is used, only the direct children of the
"feature" under test are exposed (without further exploration). In my
example, the user would be aware that the card contained a heading, but not
that the heading contained a link.

However if the link wrapped the heading, the user would be aware that the
card contained a link, but not that the link contained a heading.

From what I have learned about screen reader usage over the years, I would
tend to navigate by the following methods instead: headings quick keys,
heading menus, link menus, or the TAB key.

However I appreciate that I am not dependent on a screen reader for daily
web navigation and users with disabilities may well have other established
patterns which serve them better.

Perhaps the BBC's approach is based on insights from user testing, whereas
mine is based on tutorials aimed at either developers, or new users of
screen readers (such as EyeT's tutorial
https://www.youtube.com/watch?v=U5XzBiPwDks).

Do you have a preference for nesting elements within links, or vice versa?


Many thanks,
Dan

From: Steve Green
Date: Thu, Nov 19 2020 7:02PM
Subject: Re: Card UX: Wrapping cards in an unordered list and Nesting when using anchor elements
← Previous message | Next message →

We encounter these sort of cards or tiles a lot. If each card contains a heading, I don't usually recommend marking-up all the cards as a list. However, I am not aware of any reason why you shouldn't. The only advantage of the list mark-up is that screen reader users are informed how many cards there are. That could be important if there are a lot or if the number changes. Otherwise, there is no benefit and it just adds noise.

If the card only contains one link, we recommend making the entire area of the card clickable by putting a JavaScript event handler on the container. However, it should not usually receive focus.

I have seen the same behaviour that you describe insofar as Voiceover on iOS only announces either the heading or the link, depending on both the nesting and how you navigate to the element. User testing shows that people use a variety of navigation methods. However, my experience is that people with average proficiency or lower tend to stick to swiping. I would therefore nest the elements such that the links are announced when swiping. If you do it the other way round, so the headings are announced, some people will never find the links. Ideally, you should do your own user testing.

Steve Green
Managing Director
Test Partners Ltd

From: Mark Magennis
Date: Fri, Nov 20 2020 2:25AM
Subject: Re: [EXTERNAL]Card UX: Wrapping cards in an unordered list and Nesting when using anchor elements
← Previous message | No next message

Hi Dan,

Like Steve, I encounter strips of cards a lot because my company uses them frequently in its products. The cards are complex, typically containing images, headings, text, links, buttons, and menus. There is no problem with putting the cards into a list.

In terms of links that are headings and whether the link is best within the heading or the heading within the link, I have found the following to be true in my testing. I've also looked at headings that are buttons.

- If a heading is a link, it is best if the link is within the heading.
- If the heading is within the link there are some issues in VoiceOver/Safari.
- If a heading is a button, the button must be within the heading.

I've only tested using Win10/NVDA/Firefox, Win10/Jaws/IE11, and MacOS/VoiceOver/Safari as this is what our customer base demands.

In NVDA/Firefox there is no difference.

In JAWS/IE11, headings that are within buttons aren't announced as headings when the button is tabbed to or arrowed to and cannot be navigated to using the 'h' shortcut. For links, there is no difference.

In VoiceOver/Safari, headings that are within buttons or links aren't announced as headings when the button is tabbed to or arrowed to. Headings within buttons cannot be navigated to using the 'h' shortcut. Headings within links can be navigated to using the 'h' shortcut but the heading level is not announced.

There may also be an affect on the clickable area because a heading is a block level element whereas a link is an inline element. So notwithstanding other CSS treatments, if the link is within the heading, only the text is clickable. Whereas if the heading is within the link, the entire rectangular area encompassing the heading becomes clickable.

Mark