Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add how-to pages for error notification #2

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Conversation

@rachaelbradley
Copy link
Contributor

rachaelbradley commented Jul 14, 2023

Summary:

The purpose of this Pull Request is to:

  1. Review the subgroup work on Error Notification
  2. Begin piloting our new process

This pull request contains the first draft of the "How To" documents for Error Notification.
Because our repositories are split, the normative text in the Guidelines are in the previous repository but referenced here.

Maturity Level: Exploratory

Action Needed for July 18th

  • Read this PR and briefly check out the links. You may add comments but will have more time after the meeting to participate
  • Consider how we can improve the how to template
  • Consider how we can improve this process

Action Needed for July 25th

  • Review content
  • Add a thumbs up if you agree with the changes, thumbs down if you do not.
  • Add comments to PR or Google Doc (Note: We will lock the Google at 8 eastern on Monday July 24th.)

Content for Review:

Normative guideline text at:

Informative How To text

@gradualclearing
Copy link

From a process perspective, it might work best to have the thumbs upping for each review task. For example, my thumbs up here is related to the process part of the July 18th task, as I haven't yet reviewed the content.

@alastc
Copy link
Contributor

alastc commented Jul 23, 2023

Overall, I can understand the logic of this set of outcomes, e.g. the first is a binary (provided or not), the second is more about the understanding, and it gets more nuanced/useful after that.

Apoligies in advance, this will be a mix of things specific to the guideline and things to do with templates and WCAG 3 approach in general.

Terminology of 'notifications'

One thing that I'm not sure about is the use of the term 'notifications'. In a web accessibility context it leads you to a particular form of error message, and implies that there should be an alert-style presentation.

An error message could be fairly static, whereas a 'notification' implies something that pops-up dynamically, e.g. a 'toast notification' or something like that.

The solution would be to pick another term, or fall-back to 'error messages', e.g.
"Outcome: Error messages provided: Provides a message about an error so users know that an error has occurred.
Outcome: Messages describe errors: Provides a clear description of the error so users understand the cause of the error."

This terminology concern is the type of thing that varies by person, and perhaps I'm unusual in this understanding. If it's just me then I'll let it go, if others got the same impression it would be worth changing.

Methods & How-tos

Just on the template, it would help to separate the name of the outcome within the breadcrumbs, currently:
WCAG 3.0 / Notifications provided Methods & How To's / User Needs
Could be:
WCAG 3.0 / Notifications provided - Methods & How To's / User Needs
Or just:
WCAG 3.0 / Notifications provided / User Needs

Looking at the user-needs page, it repeats the 'barriers encountered' heading multiple times, but I can't see any context for why there are multiple (different) section?
Perhaps it is a template thing I've missed, but it needs a little context, e.g. a one line paragraph under each heading, before the list.

Method - Tests (Error messages need to be discernible, consistent, and accessible)

I think there needs to be some definition or description of when something is an error message.

Perhaps that should be a level up from here, but one of the key things in WCAG 2.x has been scoping - when does this requirement apply (or not). That is not clear from following the path down from the outcome to the method and test.

E.g. if you do a search and get no results, is that an error? If you get your username or password wrong, and it can't tell you which is wrong for security reasons, what then?
If it provides a hint that you might want to provide different information (but will let you through if you are sure), is that an error message?

Methods index

When reviewing 'The technology stack supports notifications', I was a bit lost, even on the introduction. I think it would help to have a summary line for each which is shown on the methods index.

It is difficult to work out (just from the title) when each method would be applicable, so some explanations would help, e.g:

Error messages need to be discernible, consistent, and accessible

  • Applies to all error messages.

The technology stack supports notifications

  • If you are relying on user-agents to provide notifications they need to provide appropriate accessibility support.

(I'm guessing on tech-stack one, I'm not sure what the applicability is intended to be.)

Method - What errors should be notified?

I'm confused by this being a method, it seems to be information that sits above the method level, or should be integrated into each method/test?

It is good info, it starts to address my comment about defining notifications, but it seems an odd place to put it as it is not a method by which I would meet the guideline.

It could be put in the "Learn how to meet guideline" bit when that is there perhaps? It would be something useful to reference from several of the methods.

@rachaelbradley rachaelbradley mentioned this pull request Jul 24, 2023
Closed
@rachaelbradley
Copy link
Contributor

Summary of Conversation in Google Doc and on Github as of July 24th 2023

Overall, general agreement with the methods with three suggestions:

  1. Change "Notification" to "Messages"
  2. Break apart "Error messages need to be discernible, consistent, and accessible method test" into "Error messages need to be discernible and accessible" and "Error messages need to be consistent"
  3. Clean up the test statements so they are written consistently

@bruce-usab
Copy link

bruce-usab commented Jul 24, 2023

Preview pages (github.io URLs) are looking really good! I was not really able to follow the flow of the material from the Google Doc version of material, and kind of gave up trying to digest it. The preview pages made it all sensible, so that was great to have both versions.

Thank you also for the sampling of methods, which varied in how technical range. From files (link at top in this PR) I especially appreciate how much is in markdown, since I think that will facilitate iteration on the material.

@rachaelbradley rachaelbradley added the Approved for Merge Consensus to merge. If you have concerns raise them now. label Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Approved for Merge Consensus to merge. If you have concerns raise them now.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants