WCAG2ICT Project: Add 2.5.1 Pointer Gestures

[maryjom]

• [x] Add 2.5.1 Pointer Gestures section (from WCAG 2.1)
• [x] Be sure to take a look at the definition of "single pointer" for potential need for interpretation. See Issue #22)
• [x] Add in the Understanding 2.5.1 Pointer Gestures Intent and Benefits sections
• [x] Consider and write up whether there are any notes needed for application of this SC to non-web technologies

[maryjom]

Current WCAG 2.2 definition of "single pointer" - seems like there isn't a need for interpretation.

single pointer pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures

[maryjom]

Original text from WCAG is:

2.5.1 Pointer Gestures (Level A)

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

NOTE This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

Some things to consider in analyzing this. Hope this is helpful @bruce-usab.

• Using the WCAG2ICT definition of "content" (on and off the web), a statement at the end says any time "web content" is used, it should be replaced by "content".
• The weird thing about this one is the parenthetic "(i.e. this does not apply to actions that are required to operate the user agent or assistive technology)". If you're applying this SC to non-web software, it would seem that the parenthetic statement should be removed, or just changed to "i.e. this does not apply to actions that are required to operate assistive technology". One would imagine you'd want non-web user agents, software, and platform software to abide by this requirement. However, I'm not sure that saying so is overreaching our TF's scope. We could perhaps note that this parenthetic phrase seems to scope out non-web documents and software, including platform software. If there is such a user need for those cases of software then standards that wish to apply WCAG may want to consider making modifications to the note to broaden the scope of application.

[mraccess77]

I don't think software and non-web documents should be scoped out if the content/functionality is created by the author rather than provided by the "user agent". This provision is applied to software by other standards like EN 301 549 and mobile apps content can control this behavior or allow it to be controlled by the platform.

I would agree that platform software is not properly addressed by applying WCAG to non-web ICT as WCAG doesn't sufficiently address accessibility features and user settings necessary to cover that topic.

[maryjom]

@mraccess77 I am unaware of any technology where a non-web document author could define content that interprets pointer gestures to operate content in the document. If you know of a non-web document technology that supports this, I'd be interested in learning more about it to share with the group. If there is such a document technology, perhaps we could improve on the note in the EN 301 549 and point out some examples and also point out that this capability is somewhat rare outside of that realm.

I realize that the EN 301 549 applies this criterion to non-web documents, and I guess the phrase of the note "documents that interpret pointer actions" would essentially scope out most, if not all, documents today. Perhaps I'm playing devil's advocate here, and my thinking is that if it doesn't exist today, then why promote another requirement for documents that is always "not applicable"? It just adds noise of what document authors need to understand, think about, and determine whether it applies to the content they're producing. It also adds another requirement a test professional would have to determine - whether or not the document author has added anything in the document that interprets gestures, and if so, discern them from gestures interpreted by the user agent (document viewer or authoring tool).

[patrickhlauke]

non-web documents, not that i'm aware either. but native (non-web) software in general, definitely can and does interpret gestures.

[mraccess77]

Hi @maryjom I was thinking of Adobe XD and Figma type files - they seem to fit the definition of a document and these types of experience prototyping could be non-web even if some of the implementation today are web based. You can create swipe gestures for particular interactions that are part of the content and not the part of user agent. Now, the user agent may help define what gestures are available through defined interactions but it's the author's choice to use these.

document (as used in WCAG2ICT) assembly of content, such as a file, set of files, or streamed media that functions as a single item rather than a collection, that is not part of software and that does not include its own user agent

[maryjom]

@mraccess77 Thanks! I'll look into those. I didn't realize that you could define actually working gestures with Adobe and Figma. Perhaps simply adding a note might help authors and test professionals more easily determine applicability of this SC to their tooling. How about something like this:

For non-web documents only. Non-web software would have to be treated separately. Note: Applicability of this success criterion would be limited to document types where interactive gesture capabilities are available for authors to add to the document. For example, prototyping tools used to design software.

[patrickhlauke]

Note: Applicability of this success criterion would be limited to document types where interactive gesture capabilities are available for authors to add to the document. For example, prototyping tools used to design software.

maybe i'm misunderstanding (likely, since I only dip in occasionally on threads here on WCAG2ICT), but: are you outright out-of-scoping software here and only applying the criterion to non-web documents?

[maryjom]

@patrickhlauke This note would be applicable to only documents, but I didn't show that in my suggested text so I understand your confusion. IMO all non-web software that supports pointer usage should have this as an applicable requirement. There are cases in the WCAG2ICT document where we handle documents and software separately. I think this is a good example of a case where such treatment would be beneficial. I updated my previous comment to be clearer. Thanks for pointing it out.

[patrickhlauke]

apologies as well for basically just looking at this through a tiny keyhole, occasionally, when i noticed things coming into my inbox, rather than making an effort to look at the wider context these small discussions are in (and then knee-jerking away)

[mraccess77]

Hi @maryjom I agree it would only be applicable when content (in this case non-web documents) interpret pointer actions. Many non-web document types do not have this capability but some do.

[samogami]

Issue #143 for review.

[maryjom]

The TF reached consensus on the guidance for SC 2.5.1 on 27 April. The AG WG reviewed 2.5.1 in the 3rd content review and approved the content on 25 July.