AGWG 8 September 2020 -- 08 Sep 2020

<Grady_Thompson> scribe: Grady_Thompson

Findable Help https://www.w3.org/2002/09/wbs/35422/findable-help-issues/results

Changing the option term

<Rachael> pull request: https://github.com/w3c/wcag/pull/1356/files

rm: findable help - changing the term "option"?

<alastairc> "For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one or more of the following help mechanisms is supported, then access to at least one mechanism is included in the <a>same relative order</a> on each page:"

<Rachael> Straw Poll: Accept the changes at https://github.com/w3c/wcag/pull/1356/files +1 to accept, -1 to discuss more

<bruce_bailey> +1

<alastairc> https://w3c.github.io/wcag/guidelines/22/#findable-help

ac: very granular changes, first sentence. not changing the meaning, just a rewording
... to improve clarity

<alastairc> PR: https://github.com/w3c/wcag/pull/1356/files

<Chuck> +1 to straw poll

rm: any other ?s before straw poll?

<Rachael> Straw Poll: Accept the changes at https://github.com/w3c/wcag/pull/1356/files +1 to accept, -1 to discuss more

<Francis_Storr> +1

<alastairc> +1, 3 issues with 1 stone.

<bruce_bailey> +1

<laura> +1

<JakeAbma_> +1

<Brooks> +1

<Fazio_> +0

<Rachael> Straw Poll: Accept the changes at https://github.com/w3c/wcag/pull/1356/files +1 to accept, -1 to discuss more

<alastairc> https://www.w3.org/2002/09/wbs/35422/findable-help-issues/results#xq1

<pwentz> +1 (if it stays binary)

<Fazio_> Good point. I'd think mechanism is something actionable

ak: may not be consistent with previous ways about talking about mechanism

rm: maybe "help option is supported"?

ak: definition of mechanism is process for achieving a result

<Rachael> Current proposal: For single page Web applications or any set of Web pages, if one or more of the following help mechanisms is supported, then access to at least one mechanism is included in the same relative order on each page:

<Rachael> AWK proposal: For single page Web applications or any set of Web pages, if one or more of the following help options is supported, then access to at least one option is included in the same relative order on each page:

pw: currently complex to read

<sarahhorton> +1 to feature

rm: github issues say that the word option makes it confusing, mechanism doesn't fit, is there another choice?

<alastairc> Needs to have "help", so "help option" would be good

<alastairc> or "help feature"

<pwentz> Proposal, complete rewording: If one or more of the the following help features is supported in single page Web applications of sets thereof, then accces to at least one option is included in the same relative order on each page

<Chuck> +1 "help feature"

[reads pw's proposal]

ac: it's a reordering.. maybe different, but not simpler

<Rachael> If one or more of the the following help features is supported in single page Web applications or any set of Web pages, then acccess to at least one option is included in the same relative order on each page.

<kirkwood> “method of finding help” rather than “option”?

<AWK> small rewording which keeps option: For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one or more of the following options for help is provided, then access to at least one of the options is included in the <a>same relative order</a> on each page:

rm: two questions: 1) the word 2) the restructuring. start with the word

<Rachael> Options: feature, option, method, mechanism

<david-macdonald> what about just dropping option

<AWK> Is text on a page a "feature"?

<pwentz> feature +1

<alastairc> Don't mind so long as it includes "help", e.g. "help option"

<Rachael> Straw poll on choices: feature, option, method, mechanism

Sukriti: didn't have clarity, like using method for help instead of mechanism or option

<kirkwood> method

<AWK> Prefer "option"

<david-macdonald> option

<pwentz> help-feature

<Raf> +1 for mechanism

<JakeAbma_> option

<alastairc> + "help method"

<Brooks> option

<Francis_Storr> option

<bruce_bailey> mechanism or option

<laura> + to option

<Sukriti> method for help/help method

<david-macdonald> nervous about method because 3.0 uses methods

<Rachael> Can anyone not live with the word option?

<Chuck> +1 option

rm: slight preference toward option

<kirkwood> I find option confusing

pw: option is something that can be turned on/off. ambiguous, doesn't support option

<alastairc> option = "a thing that is or may be chosen."

<david-macdonald> define option "a thing that is or may be chosen. "choose the cheapest options for supplying energy" "

<laura> +1 to dm’s suggestion to add a definition for the word “option”

ak: doesn't like feature, an email address doesn't feel like a feature. an option is one of a set of choices that are provided. email address, phone number, physical address are options that people can choose to include on a page

<david-macdonald> 1q+

<Rachael> Can anyone not live with the word method?

<kirkwood> provide a method for helping. +1 to method

<pwentz> +1 to kirkwoods wording.

dm: using methods a lot. using "method" in different way in 3.0 could cause confusion

<Sukriti> means of finding help?

<laura> good point

<CharlesHall> +1 to David.

<kirkwood> +1 to sukriti: “means of finding help”

ac: methods and mechanisms are both clashes. option seems appropriate based on dictionary definition. other words have extra meanings.

<CharlesHall> ‘way’ is even simpler than any of these terms. a way to do a thing.

<ChrisLoiselle_> user assistance reference path / customer service channel choice?

Sukriti: suggests "means of finding help"

<pwentz> Prefer "means" to "options"

<kirkwood> +1 to means

<pwentz> Can't live with options, because You have the following three options, from one of which is exclusive, also. You can turn on/off the option X in ...

RM: means and ways suggested now - is there a preference? we have excluded every other word

<Raf> +1 for options

<laura> +1 to ways

<JakeAbma_> option

RM: or any additional suggestions?

<bruce_bailey> +1 to "way" -- not used elsewhere

<kirkwood> either means or ways are fine

<david-macdonald> +1 options

<alastairc> +1 option

<david-macdonald> could live iwth others

<pwentz> +0.5 means +0.5 ways

<Chuck> For single page Web applications or any set of Web pages, if one or more of the following ways of finding help is supported, then access to at least one way of finding help is included in the same relative order on each page:

AC: doesn't understand PW's understanding of option

<kirkwood> -1 to options agree with Pascal

PW: option, like a setting, can be turned on/off

<Chuck> For single page Web applications or any set of Web pages, if one or more of the following means of finding help is supported, then access to at least one means of finding help is included in the same relative order on each page:

<david-macdonald> " Car options are add-ons for a vehicle that a buyer of a new car can choose before purchase. "

<david-macdonald> (not exclusive)

<AWK> For single page Web applications or any set of Web pages which provide one or more of the following, then at least one is included in the same relative order on each page:

CA: reconstructed sentence to include both - prefers "ways of finding help"

<Rachael> For single page Web applications or any set of Web pages, if one or more of the following ways of finding help is supported, then access to at least one way of finding help is included in the same relative order on each page:

<david-macdonald> +AWK

<laura> +1 to ways

<Levon> I think it reads simply and clean (ways).

<bruce_bailey> seems like plain language

<bruce_bailey> +1 for ways

<kirkwood> +1

<pwentz> +1

<Sukriti> +1

<Chuck> +1 ways

<Brooks> +1 ways

<alastairc> For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one or more of the following help options is supported, then access to at least one option is included in the <a>same relative order</a> on each page

RM: let's look at original wording to compare

<alastairc> Current draft: For single page Web applications or any set of Web pages, if one of the following is available, then access to at least one option is included in the same relative order on each page:

<Rachael> AWK's proposal: For single page Web applications or any set of Web pages which provide one or more of the following, then at least one is included in the same relative order on each page:

RM: solid majority support for "ways". straw poll on alternate above

<laura> can live with either

<Chuck> +1 AWK version

<pwentz> +1 AWK

<alastairc> +1 to propose back to the commenters

<bruce_bailey> can live w/ either, but AWK proposal better matches 2.x pattern

<Raf> +1 for both.

RM: propose both or just one?

AC: propose one, but we explored both. none of these two fit particularly well

<Rachael> Option 1: For single page Web applications or any set of Web pages, if one or more of the following ways of finding help is supported, then access to at least one way of finding help is included in the same relative order on each page:

<Rachael> Option 2: For single page Web applications or any set of Web pages which provide one or more of the following, then at least one is included in the same relative order on each page:

<sarahhorton> Option 1

[Straw poll on which option is preferred- to propose back to commenters]

<Detlev> option 1

<bruce_bailey> +1 for option 2

<alastairc> option 2

<Chuck> +1 Option 2

<AWK> Option 2 (but can live with 1)

<Raf> option 2

<pwentz> Option 2

<laura> Option 2

<Francis_Storr> option 2

<kirkwood> option 2

<Rachael> option 1

<Levon> option 1

<Rachael> Should we restructure: If one or more of the the following help features is supported in single page Web applications or any set of Web pages, then acccess to at least one option is included in the same relative order on each page.

<Chuck> +1 leave as is

RM: now should we restructure, can we fit new wording or should we leave it as is?

<Rachael> if one or more of the following ways of finding help is supported in single page Web applications or any set of Web pages, then access to at least one way of finding help is included in the same relative order on each page:

<Rachael> Option 2: If one or more of the the following help features is supported in single page Web applications or any set of Web pages, then acccess to at least one option is included in the same relative order on each page.

<sarahhorton> Option 2

<Wilco> option 1

<Sukriti> option 1

<AWK> 1

<laura> 1

<bruce_bailey> option 1

<Ryladog> 1

<kirkwood> option 1

<Chuck> 1

<david-macdonald> #1

<Levon> option 1

<Francis_Storr> option 1

RESOLUTION: Accept option 1 of AWK's amended language for PR #1356

Same relative order term #1230

AC: comment was around same relative order not making sense. Sukriti suggested response [reads response]
... definition of same relative order includes position

<Rachael> Straw poll: approve response

RM: any comments before approving the response? no comments

<sarahhorton> +1

<laura> +1

<Chuck> +1

<bruce_bailey> +1

<Rachael> +1

<Raf> +1

<Ryladog> +1

<Brooks> +1

<alastairc> +1

<Francis_Storr> +1

<Levon> +1

<kirkwood> +1

<david-macdonald> +1

RESOLUTION: Agree with proposed response

Is one option enough? #1235

RM: public comment that suggests that all help options be available in one place

<Rachael> Draft response is at: https://github.com/w3c/wcag/issues/1235#issuecomment-683195264

Sukriti: at least one contextual help option available instead of overwhelming user with all options on one page

SH: all of the different ways of getting help available on every page, instead of a link on every page to a different page that lists all help options. SC would be met if that was the case. but it didn't match

AC: modify the response, instead of modifying the SC
... maintain flexibility for the ways various organizations and Web sites can meet the SC

AWK: unclear about quoted text

RM: adjusting so it's a group response, not individual
... asks Sukriti to post updated draft response

<Chuck> +1 agree to amend and review later

RM: straw poll of the intent to not make an update

<Rachael> straw poll: Is the intent correct?

<Raf> +1

<bruce_bailey> +1 agree w/ intent

<Wilco> +1

<Ryladog> +1

<Rachael> +1

<kirkwood> +1

<alastairc> +1, I'll make a suggestion in the thread

RESOLUTION: revise response for later review

<alastairc> Suggested update: https://github.com/w3c/wcag/issues/1235#issuecomment-688971199

Available or provided? #1232

RM: we have a draft response, need to clarify wording to make the intent clearer

<pwentz> would vote for provided, because available doesn't have to mean the user can actually use it...

AWK: "supported" would work great if it was a a mechanism. for example, for email address, provided or available seems better

<Rachael> Straw Poll: Already used wording (For single page Web applications or any set of Web pages, if one or more of the following ways of finding help is supported, then access to at least one way of finding help is included in the same relative order on each page:) be used to answer this.

<AWK> For single page Web applications or any set of Web pages which provide one or more of the following, then at least one is included in the same relative order on each page:

<Rachael> Straw Poll: Can we use the wording above to answer this question. +1 to agree, -1 to explore another response

<bruce_bailey> +1 agree

<Wilco> +1, provided seems the right word

<AWK> +1

<kirkwood> +1

<pwentz> +1

<Chuck> +1

<Brooks> +1

<Raf> +1

<Detlev> +1

<laura> +1

<Francis_Storr> +1

<sarahhorton> +1

RESOLUTION: Use AWK's proposed wording to respond

<Levon> +1

<ChrisLoiselle_> scribe:ChrisLoiselle

<ChrisLoiselle_> scribe:ChrisLoiselle_

What is self-help? #1229

<Rachael> https://github.com/w3c/wcag/pull/1376/files

Rachael: Any concerns in the survey?

Wilco: Does provided by author adds much?

AlastairC: I think difference is on what type of help was provided. I.e. the author vs. researching on another website.

SarahH: Feature may talk to this , in that it is provided by the author.

<Brooks> So, an FAQ would qualify as "self help?"

<Rachael> current text: self-help option

<Rachael> proposal: Self-help option provided by the author

<Rachael> Sarah's proposal: Self-help feature provided by the author

Chuck: Brings up Brooks question, so an FAQ qualify as self help?

Rachael: My understanding is yes.

Wilco: Could we add in "such as", which would give an example of self help.

<Rachael> Rachael's proposal: Self-help provided by the author

Rachael: We moved it to understanding.

<alastairc> How about "Help content provided by the author"?

<kirkwood> +1 to Alastairs

<Detlev> +1 to Alastair's wording

<Ryladog> +1

<Wilco> +1

<Brooks> +1 to Alastair's wording

<Rachael> Straw poll: Help content provided by the author

<Sukriti> +1

<Wilco> +1

<Brooks> +1

<Chuck> +1

<kirkwood> +1

<sarahhorton> +1

<Francis_Storr> +1

Wilco: That addresses my concern.

<laura> +1

<bruce_bailey> +1

RESOLUTION: Use Alastair's proposed response "Help content provided by the author"?

<Sukriti> https://github.com/w3c/wcag/pull/1376

Being responsible for content #1303

<Rachael> https://github.com/w3c/wcag/pull/1366/files

Issue 1303 Clarification on responsible for content

AlastairC: Talks to part of the organization that can assist with the content , rather than is responsible for the content.

AWK: I'm fine with it either way.

Rachael: Any other questions before straw poll?

<Rachael> Straw Poll: Accept the pull request

<alastairc> +1

<Rachael> +1

<Grady_Thompson> +

<sarahhorton> +1

<AWK> +1

<Sukriti> +1

Changing from responsible for, to "that can assist with".

<Chuck> +1

<bruce_bailey> +1

<Wilco> +1

<Brooks> +1

<kirkwood> +1

<Rachael> Proposed response: We have changed "responsible for" to "that can assist with" to address your comment. Regarding the point about each layer of contact, the phrase only appears in the context of the paragraph that talks explicitly about human contact details. Within context it means the number of steps a user has to go through to reach someone who can help. We have left it unchanged for now.

<sarahhorton> +1

<laura> +1

<Rachael> Straw Poll: Approve proposed response

<Brooks> +1

<kirkwood> +1

<Rachael> +1

<alastairc> +1

<Grady_Thompson> +

<bruce_bailey> +1

<Grady_Thompson> yes, =1

<Grady_Thompson> +1

RESOLUTION: Accept PR #1366 and additionally Rachael's proposed amendment to the response

<Sukriti> Requiring all sites to have a dedicated page for all help options, especially for bigger sites can be confusing and disorienting for a user, defeating the purpose of the SC to provide a consistent and cognitively easy way to access help from all pages. It will also fail on smaller or single page applications with only 1-2 help options. It would be nice to be able to say exactly which of the available methods make most sense in a given context for [CUT]

re-review Is one option enough? #1235

<alastairc> https://github.com/w3c/wcag/issues/1235#issuecomment-688971199

Sukriti: Only the first bit changed.

Rachael: Any other comments?

<Rachael> straw poll: Accept proposed wording

<laura> +1

<bruce_bailey> +1

<Sukriti> +1

<Chuck> +1

<Francis_Storr> +1

<kirkwood> +1

<Grady_Thompson> +1

<sarahhorton> +1

RESOLUTION: Accept Sukriti's amended response

<Brooks> 0

<Detlev> +1

RESOLUTION: Accept Sukriti's amended response

Pointer target spacing: https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results

<Levon> Minor grammar;Requiring all sites to have a dedicated page for all help options, especially for bigger sites, can be confusing and disorienting for a user, defeating the purpose of the SC to provide a consistent and cognitively easy way to access help from all pages. It will also fail on smaller or single page applications with only 1-2 help options. It would be nice to be able to say exactly which of the available methods make most sense in a given c[CUT]

Understanding note gives the wrong rationale? #1362

<Rachael> pull request: https://github.com/w3c/wcag/pull/1379/files

AlastairC: It is updating the understanding document to describe the purpose of the success criteria.

<Rachael> Straw poll: Accept pull request at https://github.com/w3c/wcag/pull/1379/files

Rachael: Any concerns?

<Chuck> +1

<Sukriti> +1

<Wilco> +1

<bruce_bailey> +1

<Detlev> +1

<sarahhorton> +1

<alastairc> +1

<Rachael> +1

<Fazio_> +0

<kirkwood> +1

RESOLUTION: Accept PR 1379

Pointer Target Spacing - target size #1311

Sukriti: The intent is to avoid accidentally hitting the target.

2.5.5. addresses the question around big enough target.

Detlev: Does this set the wrong incentive? Maybe this can be separated out? I.e. decrease target size incentive ?

AlastairC: She is asking can we recommend a minimum . Our next item is about the incentive around smaller target

<Rachael> Straw Poll: Accept the reponse as proposed

<Chuck> +1

<bruce_bailey> +1

<Detlev> +1

<kirkwood> +1

<sarahhorton> +1

<Rachael> +1

<Sukriti> +1

<Wilco> +1

RESOLUTION: Accept proposed response

Overlapping Spacing #1312 & #1361

<alastairc> https://github.com/w3c/wcag/issues/1361#issue-687723200

AlastairC: Talks to pointer target spacing and unintentional incentive to reduce target size to pass criterion.

We either accept it and hope that people don't do this or we update the success criteria to not allow this to happen.

<alastairc> Vertical lists: https://github.com/w3c/wcag/issues/1384

Detlev: It brings it up that maybe this so difficult to meet that it won't be accepted to achieve as a Success Criteria? Perhaps someone can talk to why we wouldn't want to define minimum target size etc.

Rachael and AlastairC: Talked to meeting the guideline and research that was reviewed at time of writing.

Detlev: Comparing desktop mouse based navigation vs. touch and larger target area, it is something to think about. I'm not convinced we are were we need to be on the SC.

<Rachael> Straw Poll: Leaving the SC unaltered, and responding +1 to respond, -1 to discuss SC

<sarahhorton> -1

<Wilco> -1

<bruce_bailey> +1

<pwentz> +1

<Sukriti> +1

<alastairc> -1 but need proposals

<Detlev> -1 with heavy heart

<Brooks> -1

<Chuck> -1

<Rachael> -1

<Grady_Thompson> -1

Pascal: A mobile device is using a different resolution than a desktop.

<Detlev> Option for discussion: 22x22px minimum size?

AlastairC, can you list the options? I lost the three you were talking to. Sorry.

Pascal: I think the value we pick is appropriate when we use it on mobile device.

<alastairc> Options:

<alastairc> - Adjust to not share spacing between targets

<alastairc> - Adjust to use a minumum of 22px (for example)

<alastairc> - drop SC

<pwentz> @ChrisLoiselle I feel misunderstood. Resolution on mobile device can be the same even if ACTUAL resolution is different, because DPI is causing the actual available resolution to be less.

<Detlev> option propsed by Jared: move to AAA (so it works together with target size)

DavidM: Based on screen size, in general, you are either using a pointer (for larger screen) or touch (for smaller screens).

Pascal, sorry. Thanks for clarifying.

<alastairc> pwentz - the device pixel density is normalized by CSS pixels

Wilco: it is a matter of finding the number

<Zakim> alastairc, you wanted to talk about other impacts, e.g. on low vision

Rachael: Another option is to drop it to AAA level.

AlastairC: On screen size, the problem there could be users that zoom. It would lead to double the impact. Implementation would be difficult.

Wilco: Clarification on screen size, are you stating that smaller screens have it?

<pwentz> ^Can avoid that problem by prohibiting device zoom level and allow it on the application

<david-macdonald> smaller

<Fazio_> What about touchscreen laptops i.e. surface pro I think is touch

Smaller would be a bigger target, i.e. you need more space when touching with your finger.

Wilco: Opposite would be possible to, i.e. larger screens may need it as well. Smaller screens have smaller sizes due to limited screen space.

<Zakim> bruce_bailey, you wanted to suggest a character size at AA, AAA could finger tip

DavidM: Dexterity issues and target size was my concern.

BruceB: Tiny target sizes with people using tablet and trying to interact with it.

Bruce, could you list out your example in IRC?

SarahH: 2.5.8 and 2.5.5 could be more explicit, similar to contrast. Minimum size be part of 2.5.8 . Relationship between AA and AAA should be more explicit.

Rachael: I would like to make sure the minimum is sufficient

<alastairc> 2.5.8 "The size of the target for pointer inputs is at least 26 by 26 CSS pixels unless a particular presentation of the target is essential to the information being conveyed."

SarahH: The research could point to the reason why we were using the specific target size recommendations.

<Detlev> Alastair, where does the 26x26 come from?

AlastairC: We could copy the AAA level SC and talk to specific examples.

Detlev: Where does 26 x 26 come from?

<Glenda> https://material.io/design/usability/accessibility.html#layout-and-typography

AlastairC: Buttons at top at google doc.

<Glenda> That is exactly what I was going to say!

<Sukriti> Google (48X48 dp) : https://developer.android.com/guide/topics/ui/accessibility/apps#large-controls Apple (44X44 pt): https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/ Microsoft (40X40 epx) : https://docs.microsoft.com/en-us/windows/uwp/design/input/guidelines-for-targeting#target-size

Sukriti: Native guidelines have different sizes

Glenda: Design guidelines are also important to review, from a testing standpoint.

<Detlev> but this is mobile

<sarahhorton> +1

DavidM: We are the web content accessibility guidelines so not just meeting mobile.

<Glenda> I think mobile would be the most restrictive…so if we make it work for mobile..it should work for larger touch screens too.

<CharlesHall> touch input can occur regardless of screen size.

<CharlesHall> plus, larger targets work for other pointer inputs

<david-macdonald> true... but there is a cost

Glenda: The challenges on mobile vs. large screen are different , however someone's hands / fingers don't change sizes. If you can work on mobile, it will work on larger screens as well.

<CharlesHall> the number is based on the finger size. not screen size.

Chuck: On design patterns, at one point can we come up with a size , at which we don't ask "is this for mobile"?

SarahH: I more research would be needed. One option I thought could be differentiate between controls and links

Detlev: As an option, we have discussed for icons, navigation, drop down navigation items , lists of content etc. it is really difficult and working with exceptions is hard.

<Glenda> can 1.4.12 Text Spacing help us out? https://www.w3.org/TR/WCAG21/#text-spacing

<alastairc> Expanding google docs https://usercontent.irccloud-cdn.com/file/Jhjnmt0s/image.png

Pointer sizes on desktop and mobile and testing out would be a start

Brooks: For touch, it is inadvertently pressing something and activating the control.

<Zakim> Rachael, you wanted to say, can we specify intent? For interfaces intended to work on touch screens

<Glenda> +1 to what Brooks is saying. Spacing and Minimum Target size!

<Zakim> alastairc, you wanted to say large screen with large touch targets will no fly

<Rachael> Straw Poll: Put together a group to craft a proposal, +1 to work it, -1 to vote on dropping or moving

AlastairC: We have been through this in wcag 2.1 , we were concerned about the negative aspects. I think we may end up at same place.

<Glenda> +1

<kirkwood> +1

<Wilco> +1

<Brooks> +1

<Chuck> +1

<Rachael> +1

<bruce_bailey> +1 for sub group

<Detlev> +1

<Grady_Thompson> +1

<sarahhorton> +1

<Sukriti> +1

<Francis_Storr> +1

<pwentz> +1

<Sukriti> +1

RESOLUTION: Put AGWG team together to continue review and craft a proposal.

<Detlev> I'm still on it

<sarahhorton> I'm in!

<Sukriti> I'm in also from MATF

<Sukriti> thank you!

<Sukriti> sorry i didn't mean to ignore - still getting used to irc

- DRAFT -

AGWG 8 September 2020

08 Sep 2020

Attendees

Contents

Findable Help https://www.w3.org/2002/09/wbs/35422/findable-help-issues/results

Changing the option term

Same relative order term #1230

Is one option enough? #1235

Available or provided? #1232

What is self-help? #1229

Being responsible for content #1303

re-review Is one option enough? #1235

Pointer target spacing: https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results

Understanding note gives the wrong rationale? #1362

Pointer Target Spacing - target size #1311

Overlapping Spacing #1312 & #1361

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output