This issue comes from our user testing round 2: content. Because it was a content type tested in test 2, there is also more information on error and warning experiences in #56's results document.
While errors and warnings could be completely accessed by assistive tech used by our participants, it was communicated ineffectively to its users. Errors and warnings were some of the most missed or most difficult to identify with participants, especially so for those using screen readers or Braille readers. This is likely because error and warning information is almost entirely visual. They also nest directly against other output types, so they can be obscured by having a standard text output and and error or warning back to back.
At the moment, errors and warnings in a rendered notebook appear
after a code cell
after a normal code cell output (if there is one)
with the error or warning raw text in the code font
with a low contrast background fill color of orange (for warnings) or red (for errors)
Of the participants who had success identifying errors, many cited their familiarity with the error messages as the reason they noticed it—they were relying on the contents of the message more than anything about the notebook.
Possible solutions
Based on current feedback, the error/warning experience might be greatly improved by the combination of:
Adding an exclamation icon (or similar) to the left of errors and warnings
Add a label word ("error" or “warning” depending on the case) to the beginning of the line
Updating or changing the way the error/warning colors appear (they either need to be higher contrast, become an outline instead of a fill, or have the color appear elsewhere entirely like in the added icon)
Acceptance criteria
This issue can be closed when we:
Merge a PR that makes the above changes to error and warning styles.
Tasks to complete
[ ] Document the current error and warning styles
[ ] Select icons for errors and warnings
[ ] Decide on a way to update the use of color in errors and warnings so that it has enough contrast and supports the message more fully
[ ] Provide a mocked up version of these changes for team review
[ ] Make PRs to add changes to error and warning rendering
Problem and context
This issue comes from our user testing round 2: content. Because it was a content type tested in test 2, there is also more information on error and warning experiences in #56's results document.
While errors and warnings could be completely accessed by assistive tech used by our participants, it was communicated ineffectively to its users. Errors and warnings were some of the most missed or most difficult to identify with participants, especially so for those using screen readers or Braille readers. This is likely because error and warning information is almost entirely visual. They also nest directly against other output types, so they can be obscured by having a standard text output and and error or warning back to back.
At the moment, errors and warnings in a rendered notebook appear
Of the participants who had success identifying errors, many cited their familiarity with the error messages as the reason they noticed it—they were relying on the contents of the message more than anything about the notebook.
Possible solutions
Based on current feedback, the error/warning experience might be greatly improved by the combination of:
Acceptance criteria
This issue can be closed when we:
Tasks to complete