How many checks?

[iadawn]

How many checks is too many?

Some other ideas around this...

One options is to group checks on the resource homepage. This would allow for more to be included without it seeming too overwhelming.

Grouping could be by theme or by difficulty.

[shawna-slh]

+100 for grouping them.

Maybe:

1. ~7 main checks
2. Additional really easy checks (expandable or separate page)
3. More difficult checks (expandable or separate page)

And maybe grouping by theme within there?

And probably grouping and/or clear indication of:

• Specific checks
  • for forms
  • for audio and video
  • other?

... not sure how that relates to the grouping above, though :-)

Some specifics in "shawn" column of Easy Checks - Prioritization (google sheet)

[iadawn]

Just to flag a comment I made in the EO meeting on 9th June; having a small number isn't necessarily the important thing. Ensuring that the overview page doesn't become overwhelming is the thing. This is where grouping will be useful.

[shawna-slh]

Should we include all the the easy checks that were in the previous version? (OK to leave off the harder ones?)

[shawna-slh]

OK here's a pass at one idea to "get the brain juices flowing" for editors discussion then EOWG discussion.

Background: Easy Checks Prioritization

---

Easy checks:

• Language
• Page title
• Orientation for apps

Core checks:

• Image text alternatives ("alt text") (pictures, illustrations, charts, etc.)
• Headings
• Text contrast ratio ("color contrast")
• Moving, Flashing, or Blinking Content
• Text spacing (or, maybe include with zoom since you’re looking for the same thing)

Video and audio checks:

• Captions
• Transcripts
• Description
• Moving, Flashing, or Blinking Content

Harder checks:

• Resize text, zoom, reflow {@@ ? together or separate ? too complex together? or too repetitive separate?}
• Keyboard access and visual focus (maybe + focus not obscured) {@@ ? together or separate ? too complex together? or too repetitive separate?}
• Form field labels

---

Maybe add later:

• ? Dragging movements - wasn’t in the priorities spreadsheet
• Focus not obscured OR maybe include as a check with keyboard access?
• Links open new windows – it’s AAA
• Skip links – it’s not required in some cases. Would it be too cumbersome to explain that?
• Lists – because it was low difficulty to explain and low difficulty to perform we might want to include it even though it's also low impact in many situations

Not including in this iteration:

• ? Reading level - AAA - while tools help, they have limitations
• Link text – when we worked on the first version, we decided this was prone to false negatives. Can revisit, but would be good to dig up issues from the to avoid re-inventing or spinning
• Required fields
• Redundant color coding – not common
• Focus order – no one argued for inclusion
• Landmarks – no one argued for inclusion
• Error handling – no one argued for inclusion
• Tables – no one argued for inclusion
• Consistent help – no one argued for inclusion
• Non-text contrast – no one argued for inclusion
• Target size – no one argued for inclusion
• Redundant entry – no one argued for inclusion
• Accessible authentication – no one argued for inclusion
• Animation from interaction – no one argued for inclusion

@iadawn @AndrewArch

[AndrewArch]

Shawn, I'm happy with your grouping & prioritisation for now. I would personally like to see readability added back in - could even be an easy check if Hemingway is accessible

[iadawn]

Couple of things that I would argue about:

• Keeping each check as atomic as possible - for example, keyboard access and visible focus checks two different (albeit related items). Grouping them in the easy check makes it more involved to explain and unpack.
• Easy checks vs core checks - not sure on the terminology
• I would not include forms as a 'harder' check but as a specific group - they are too ubiquitous a barrier not to touch on with some degree of focus
• I would prefer to avoid any mention of something being 'harder' - will tend to make people think that and either avoid or struggle with the thing

[shawna-slh]

To clarify -- one idea above was just to have something concrete to discuss — it was not meant to be a proposal at all. I added text to hopefully make more clear.

[AndrewArch]

On reflection I'm wondering if we try and group the checks by what people will be checking, e.g.:

• Structure
• Navigation
• Multimedia
• Forms
• etc.

We might end up with a miscellaneous group at the end, but I think this type of grouping would be better than Easy, Core, Harder mixed in with Multimedia and other information-type groupings

[shawna-slh]

If all the checks can be made easy, then I fully support that idea.

My big concern is how often we've heard, "this is not easy" -- from users in hands-on WAI tour sessions to recent usability testing of the prototypes. (a few notes about that in https://github.com/w3c/wai-easy-checks/issues/84 )

My gut feeling is that we'll want to ease users in with some really easy checks first. And, we'll probably want to indicate some that might be harder, in respect for the audience.

And, I'm quite happy to be wrong -- that we craft all checks to be pretty easy to most audiences! :-)

(And even if we did re-title it, I think we still have the same purpose, audiences, use cases, etc.) (note not to let this issue tangent into the title discussion - if we want to revisit that, it should be a new issue or discussion.)

[shawna-slh]

I also agree that we don't need to make final decisions on grouping for a while.

One idea for approach:

• Finish up quick drafts of the checks that we will probably include in the first iteration (but not spend much time on the ones we're not sure EOWG will want to include)
• Bring those to EOWG for eagle review along with questions on potential grouping.

[iadawn]

Please move this to the dicussion #144