Add task-list component macro

[edwardhorsford]

Description

This PR adds the Task list component from the GOV.UK Design system. It's a WIP for discussion.

The template and sass are copied from GOV.UK's task list with minor changes:

• Hover colour adjusted as NHSUK page background are already a shade of grey.

Here's what it looks like:

Tags

The main thing to resolve is what to do about tags. On the GOV.UK task list, completed and cannot start yet statuses are not tags - they are plain text. The tags are the same size as body copy. On NHSUK, tag text is a smaller size.

We could:

1. Leave as is - completed and cannot start yet have larger size.
2. Use tags for 'completed' and 'cannot start yet' instead of text.
3. Make the statuses the same text size as tags, but no other styling
4. Increase the font size of tags (like GOV.UK did).

I'm hesitant that adjusting tags might be a can of worms, and was one of the main reasons the GOV.UK component took so long to be released - so doing the minimal changes for this component would be preferred.

Checklist

• Tested against our testing policy (Resolution, Browser & Accessibility)
• Follows our coding standards and style guide
• CHANGELOG entry

[edwardhorsford]

Option 2: Use tags for all statuses

Option 3: Make the statuses closer to tags, but no other styling

Option 4 With tags adjusted to increase font size and remove bold

[anandamaryon1]

This is great, thanks @edwardhorsford

I agree that for this component, it'd be best to not have to redo tags (though I do like option 4).

For now, my preference is Option 3, as it avoid redesigning tags, doesn't look broken like Option 1, and it improves readability / scanning by reducing the number of tag colours used.

[edwardhorsford]

First revision after chatting with @frankieroberto and @anandamaryon1

Changes:

• making non-text statuses the same size and spacing as tags, though not bold
• minor css tweaks
• added an example with multiple sections

[cjforms]

Is there any chance that we could test a version where the statuses are given as:

• plain text when there is no action that you can take
• a link where there is an action that you can take, and that works the same as clicking on the substantive task

The addition of tags has always seemed like an unnecessary complication to me, and your discussion of the options for the text in them just seems to me to add even more complication.

(Possibly related: I discovered today that the Probate Service is using a thing that looks rather like a task list, but where they have removed any option to view or start to complete sections in the order that the user prefers - which negates the entire purpose of the thing).

[edwardhorsford]

plain text when there is no action that you can take

We're hoping to release this initially without requiring changes to tags - primarily copying the GOV.UK task list component as reference - but intend to come back and look at tags in a follow-up bit of work.

Assuming we don't want to use tags for 'completed' and 'cannot start yet', that leaves us with a choice: We can leave non-tag statuses as body text, but then they look visually inconsistent next to the tags; Or else we can give them styling to make them more consistent with tags, but they will be smaller. It sounds like your preference is to the former (option 1).

a link where there is an action that you can take, and that works the same as clicking on the substantive task

I'm not entirely sure what you're describing here - could you say more? Users can click the entirety of the task to open it. Clicking anywhere in the row or the link does the same thing (same as GOV.UK).

[cjforms]

We're hoping to release this initially without requiring changes to tags - primarily copying the GOV.UK task list component as reference - but intend to come back and look at tags in a follow-up bit of work.

Great, happy to hear that.

Assuming we don't want to use tags for 'completed' and 'cannot start yet', that leaves us with a choice: We can leave non-tag statuses as body text, but then they look visually inconsistent next to the tags; Or else we can give them styling to make them more consistent with tags, but they will be smaller. It sounds like your preference is to the former (option 1).

Yes.

a link where there is an action that you can take, and that works the same as clicking on the substantive task

I'm not entirely sure what you're describing here - could you say more? Users can click the entirety of the task to open it. Clicking anywhere in the row or the link does the same thing (same as GOV.UK).

I know that we know that users can click anywhere in the row, but it doesn't give much affordance for clicking.
I mean: have (say) 'Incomplete' look like a link that goes to the same place that clicking on the tag would take you to.

I do realise that there's a link on the left (in this example, 'Declaration') that goes to the same destination as the current tag/ suggested 'link' on the right (in this example, 'Incomplete') but we - and users - don't care that the whole panel is clickable but only the word 'Destination' looks like a link.

It's very similar to the problem we had some time ago with the GDS elements that styled the clickable area around small-target radios / checkboxes with a grey background to try to tell users that it was clickable - but lots of them didn't realise (irrespective of web-savviness) so that's why I proposed having the large-target radios/checkboxes, Joe Lanman tried it in a service, and then loads of people had to work hard to make it happen (hooray).

In the task list, I know there's the grey band that's meant to show the whole panel is clickable but I don't think it's enough. The tags are ambiguous - they look a bit buttony, so some folks may interpret them as buttons, but they don't look exactly like actual buttons so I think they are not buttony enough to appear reliably clickable. Whereas 'link' is a true Internet basic that pretty much everyone has to learn.

[anandamaryon1]

Thanks @cjforms, interesting points.

The main affordance that the task can be clicked is its title which is a standard link, the hover effect and the fact you can click the whole row just adds additional backup to this, in my view. I'm not convinced that replacing the tags with links would necessarily be an improvement.

My main concerns with having two links would be:

• additional cognitive load of deciding which link to click
• having two links to the same place is generally bad for accessibility
• the 'tag links' would not make sense out of context eg. to screen reader users
• they would add additional items to tab through the list when navigating via keyboard
• we'd lose the additional visual communication of the statuses that the colour coding of tags provides (to users that can see the colours at least)

[cjforms]

@anandamaryon1

Perhaps I wasn't entirely cleat that I'm requesting that my suggestions get tested?

The underlying principle here is to see whether the more complex item (the task list) can work with the simplest possible building blogs - that is, no tags.

I accept your point that in general we avoid having two links that go to the same place, but then in general we avoid introducing less familiar components.

We would also be increasing the amount of tabbing when using the keyboard alone, but we are only using a task list in the context of a highly complex form where a bit of tabbing is going to be minor compared to the overall workload of understanding the task list and dealing with the many entries that it includes.

That's why I'm suggesting testing the task list made from the simplest possible components.

[frankieroberto]

@edwardhorsford is this ready for review now, or still work in progress?

[edwardhorsford]

Have updated the PR to add a minimal readme and update the changelog.

[frankieroberto]

Looks good to me. Checked in browser at different mobile widths.

[wellhairy]

Hi. I hope this is useful. While using this pattern i've come accross a few things that i think could be improved. These are likely things that are also present in the govuk implimentation.

We're using display: table; on the .nhsuk-task-list__item and display: table-cell on the .nhsuk-task-list__name-and-hint this results in longer tags, like cannot start yet, becoming truncated when using a longer title or at smaller screen sizes.

This can be addressed by replacing display: table; on the .nhsuk-task-list__item with dispaly: flex; align-items: start; and by replacing display: table-cell on the .nhsuk-task-list__name-and-hint with flex: 1; dispaly: block; and removing vertical-align: top;

Also, the hint text is limited buy the tag. This is because the hint text is grouped with the title. It'd be ideal if we could ungroup these items and let the hint text take up the whole content area i think it'd be better, especially, for smaller devices. in addition to this we could consider using the reading width function so it never expands bigger than an optimal reading length.

I'll be doing this in my prototype but this change is a bit more complicated than a few lines of css so i've attached a couple of screen shots to show the difference. If you'd like me to share the files i'd be more than happy to but this is more or less achived by adding flex-wrap: wrap; to the list__item and moving the tag so it sits on the same level between the title and hint

Before

After

[anandamaryon1]

@wellhairy Thanks for testing out those ideas.

I agree that the tags wrapping is slightly ugly, but I'm not sure that your solution totally fixes it, I've given it a quick go and tested it with some ugly content:

Perhaps it needs some kind of max-width as a percentage with flex-basis? But I don't think it's possible to have it both ways: to have the content always display nicely and the tags never wrap.

On your other point, with the hint text wrapping beneath the tags, I feel this one will make the tags and word statuses harder to scan and result in a more messy/complex layout overall.

[wellhairy]

Hi @anandamaryon1 thanks for looking at this.

I'll mock something up later today while i'm prototyping but as a quick response:

Tags could be wrapped and aligned left for smaller devices either above or below the heading. Aligning the content (tags, headings and hint text) left to right will give users a consistent starting point to read text from and this should improved scalability. Doing this should also be visually less cluttered UI what will allow the type to breath and should provide the content better clarity.

I've discussed the use of flex-basis to facilitate this and i've had some reflection on it. We could use flex-basis but it may be the case that tags would collapse inconstantly what could be an issue for user expectation.

A different way of doing this would be by setting a max-width, possibly using ems, that would be set to a similar width as "cannot start yet" (or roughly 120px) and then using a breakpoint to collapse the tags at mobile. Using a breakpoint will give much more flexibility to update css values and control over when this break happens. This method would still use flexbox above mobile to control alignment predictably.

[anandamaryon1]

@edwardhorsford Just doing some testing on the task list in the Accessibility Lab today and found a potential improvement: on both mac voiceOver and windows NVDA, when focussing on a task link, the status is not announced (as it is on the GOV.UK version, which seems helpful).

I'm pretty sure it's because the aria-describedby="before-you-start-1-status" is on the containing div rather than the a which has the content. Likewise with the tag's id, which is on the containing div rather than the strong. Have tested this locally in dev tools and it seems to fix it.

[frankieroberto]

@anandamaryon1 good catch! I vaguely recall that aria-describedby only worked reliably on UI elements like links and buttons.

This does mean that it doesn’t work with tasks that don't have links as they cant’t be started yet - the GOVUK one just doesn’t use aria-describedby for those. Possibly that's ok in that instance as it can just be considered regular content?

We might also consider adding role=list to the ul as some screen readers don’t announce it as a list if it doesn’t visually look like a list. But whether that's a good idea or not is an open question. See alphagov/govuk-prototype-kit#1009

[edwardhorsford]

@anandamaryon1 good catch!

I think this was an accident on my part - I didn't like that the statuses didn't read if there wasn't a link - it felt better that all tasks consistently have a status. I think this was my code testing this - but it wasn't intended to be included.

I've updated to restore the aria-describedby to the anchor. I don't think it's great that the non-link tasks aren't consistent in the same way, but it matches GOV.UK so I guess we could leave as is and always discuss it later.