app/templates/components/task-list.html

{% macro task_list_item(completed, label, link) %}
  <li class="task-list-item">
    <span aria-describedby="{{ label|id_safe }}"><a class="usa-link" href="{{ link }}">{{ label }}</a></span>
    {% if completed %}
      <strong class="task-list-indicator-completed" id="{{ label|id_safe }}">Completed</strong>
    {% else %}
      <strong class="task-list-indicator-not-completed" id="{{ label|id_safe }}">Not completed</strong>
    {% endif %}
  </li>
{% endmacro %}

{% macro task_list_wrapper() %}
  <ul class="task-list">
    {{ caller() }}
  </ul>
{% endmacro %}
Make task list read better for screen readers This duplicates how the task list pattern is coded in the GOV.UK Prototype kit[1]. It adds ARIA attributes and the use of a semantically-meaningful element (`<strong>`) to give more information to screen reader users. 1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list 2018-09-21 14:24:31 +01:00			`{% macro task_list_item(completed, label, link) %}`
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765 2018-08-23 14:15:16 +01:00			`<li class="task-list-item">`
- Removed links to the gov uk stylesheets - Deleted /stylesheets folder - Removed sass build from gulpfile - Changed gov links to usa links - Changed other govuk styles, like breadcrumbs - Changed name of uk_components file to us_components - Fixed a few tests that broke on account of the changes 2023-08-08 16:19:17 -04:00			`<span aria-describedby="{{ label\|id_safe }}"><a class="usa-link" href="{{ link }}">{{ label }}</a></span>`
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765 2018-08-23 14:15:16 +01:00			`{% if completed %}`
Make task list read better for screen readers This duplicates how the task list pattern is coded in the GOV.UK Prototype kit[1]. It adds ARIA attributes and the use of a semantically-meaningful element (`<strong>`) to give more information to screen reader users. 1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list 2018-09-21 14:24:31 +01:00			`<strong class="task-list-indicator-completed" id="{{ label\|id_safe }}">Completed</strong>`
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765 2018-08-23 14:15:16 +01:00			`{% else %}`
Make task list read better for screen readers This duplicates how the task list pattern is coded in the GOV.UK Prototype kit[1]. It adds ARIA attributes and the use of a semantically-meaningful element (`<strong>`) to give more information to screen reader users. 1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list 2018-09-21 14:24:31 +01:00			`<strong class="task-list-indicator-not-completed" id="{{ label\|id_safe }}">Not completed</strong>`
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765 2018-08-23 14:15:16 +01:00			`{% endif %}`
			`</li>`
			`{% endmacro %}`

			`{% macro task_list_wrapper() %}`
			`<ul class="task-list">`
			`{{ caller() }}`
			`</ul>`
			`{% endmacro %}`