Add how-to pages for error notification

[WilcoFiers]

Add user needs pages for 4 Error notification outcomes, along with a few sub-pages

Previews available here:

• Notifications describe errors

  • Clear error language method
  • Clear error language method test

• Notifications provided

  • Error messages need to be discernible, consistent, and accessible method
  • The technology stack supports notifications method
  • What errors should be notified method
  • What errors should be notified method test

• Instructions provided to remedy errors

• Timely and targeted guidance

[rachaelbradley]

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:

• Code in PR
• Code in GitHub Preview
• Google Doc

Informative How To text

• Code in PR
• Previews:
  User Needs - Notifications describe errors
  Method - Explain the error in clear language Introduction
  Method - Explain the error in clear language Test
  User Needs - Notifications provided
  Method - Error messages need to be discernible, consistent, and accessible method test
  Method -The technology stack supports notifications Introduction
  Method - What errors should be notified Introduction
  Method - What errors should be notified test
  User Needs - Instructions provided to remedy errors
  User Needs - Timely and targeted guidance
• Google Doc - Same as above

[gradualclearing]

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]

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]

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]

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.