HHS/Head-Start-TTADP

Accessibility Review Results: New Activity Report screen/flow

Closed this issue · 1 comments

Screen reader testing findings:

  • Buttons for the activity reporting process show statuses such as "In progress", "Not Started", "Complete" etc. but those states are not conveyed to screen reader users due to aria-label overriding the text contents of the buttons. See screenshot:
    tta screenshot of buttons with their labels missing key information
  • Both date input fields use implicit (wrapped) labels, and it appears that the placeholder content of "Date" overrides the more specific and helpful label contents. See screenshot:
    tta screenshot of voiceover and the placeholder date content
  • Screen reader users are confusingly forced to deal with the datepicker widget, as it appears on focus into the date input field with keyboard focus shifted to it. Recommend only opening the datepicker if users want it by activating the button to open the calendar widget.
  • "Duration" unclear as a label. Suggest something like "Duration in hours" or "Duration in days" to ensure the end user understands what the numeric values represent.
  • Subsequent aria-live region updates for the auto-save alert only announce the date and time without any context of what the message means. In order for the entire message to be read (e.g. "This report was automatically saved on 03/01/2021 at 11:42 am", instead of only the updated text timestamp, aria-atomic='true' needs to be added to the live region to override the default. This also occurs when the "Save draft" button is pressed (see video).
  • Clicking on the "Save & Continue" button does not shift focus or provide feedback that the page have changed to the next item, Topics and resources. Clicking "Save & Continue" again announces an error on the new form ("Please select at least one topic"), but focus again does not shift to the error message. Recommendation: accessible page/route transitions and accessible form error handling needs to be approached strategically to be appropriately and consistently applied in this application.

Accessibility Insights for Web findings:

  https://tta-smarthub-staging.app.cloud.gov/activity-reports/7/activity-summary
  3/1/2021, 4:29:28 PM UTC
  WCAG 2.1 test results using Accessibility Insights for Web for the TTA Smart Hub - New Activity Report flow. Note: there are other findings from screen reader testing which have been added above this.

Keyboard - 1 failure

No keyboard traps:

  • Users must be able to navigate away from all components using a keyboard-WCAG 2.1.2
    • Comment: Goals selector dropdown when one (or more) goal is in it causes a keyboard trap - unable to tab forward out of the select.

Focus - 2 failures

Visible focus:

  • Components must provide a visible indication when they have the input focus-WCAG 2.4.7
    • Comment: skip nav link, when focused, is not visible

Revealing content:

  • Activating a component that reveals hidden content must move input focus into the revealed content-WCAG 2.4.3
    • Comment: pressing continue button does not shift focus to new/revealed form content - focus stays on button

Errors/status - 1 failure - MINOR

Error suggestion:

  • If an input error is automatically detected, guidance for correcting the error must be provided-WCAG 3.3.3

Parsing - 1 failure - MINOR

Parsing:

  • Elements must have complete start and end tags, must not contain duplicate attributes, and must be nested according to their specifications-WCAG 4.1.1

Adaptable content - 2 failures

Resize text: - MINOR

  • Users must be able to resize text, without using assistive technology, up to 200% with no loss of content or functionality-WCAG 1.4.4
    • Comment: text overlaps on page when using browser zoom at 200%

Hover / focus content: - MINOR

  • Content that appears on focus or hover must be dismissible, hoverable, and persistent-WCAG 1.4.13
    • The datepicker widget appears on focus, obscures the label and hint text content, and is not dismissible without selecting a date from the picker. Note: there is mention of the esc/escape key to close the modal in the help window, but it does not work as described.

All issues have either been remediated or issues created in JIRA. Closing this