Closed maryjom closed 1 year ago
From Guideline 2.5:
Make it easier for users to operate functionality through various inputs beyond keyboard.
In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.5 applies directly as written.
Intent from Understanding Guideline 2.5 in Understanding WCAG 2.2 (View collapsible version of guidance for Guideline 2.5):
All functionality should be accessible via pointer input devices, for example, via a mouse pointer, a finger interacting with a touch screen, an electronic pencil/stylus, or a laser pointer.
People operating pointer input devices may not be able to carry out timed or complex gestures. Examples are drag-and-drop gestures and on touch screens, swiping gestures, split taps, or long presses. This Guideline does not discourage the provision of complex and timed gestures by authors. However, where they are used, an alternative method of input should be provided to enable users with motor impairments to interact with content via single untimed pointer gestures.
Often, people use devices that offer several input methods, for example, mouse input, touch input, keyboard input, and speech input. These should be supported concurrently as users may at any time switch preferred input methods due to situational circumstances, for example, the availability of a flat support for mouse operation, or situational impediments through motion or changes of ambient light.
A common requirement for pointer interaction is the ability of users to position the pointer over the target. With touch input, the pointer (the finger) is larger and less precise than a mouse cursor. For people with motor impairments, a larger target makes it easier to successfully position the pointer and activate the target.
Do not design content in a way that is known to cause seizures or physical reactions.
In WCAG 2.0, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.3 applies directly as written.
Intent from Understanding Guideline 2.3 in Understanding WCAG 2.2 (View collapsible version of guidance for Guideline 2.3):
NOTE: The understanding's Intent for Guideline 2.3 is unchanged from previous versions and a WCAG issue was opened to address that.
NOTE: Guideline 2.4 is unchanged except for updates to the understanding that need incorporation with no changes.
Intent from Understanding Guideline 2.4 in Understanding WCAG 2.2 (View collapsible version of guidance for Guideline 2.4):
The intent of this guideline is to help users find the content they need and allow them to keep track of their location. These tasks are often more difficult for people with disabilities. For finding, navigation, and orientation, it is important that the user can find out what the current location is. For navigation, information about the possible destinations needs to be available. Screen readers convert content to synthetic speech which, because it is audio, must be presented in linear order. Some Success Criteria in this guideline explain what provisions need to be taken to ensure that screen reader users can successfully navigate the content. Others allow users to more easily recognize navigation bars and page headers and to bypass this repeated content. Unusual user interface features or behaviors may confuse people with cognitive disabilities.
Navigation has two main functions:
This guideline works closely with Guideline 1.3, which ensures that any structure in the content can be perceived, a key to navigation as well. Headings are particularly important mechanisms for helping users orient themselves within content and navigate through it. Many users of assistive technologies rely on appropriate headings to skim through information and easily locate the different sections of content. Satisfying Success Criterion 1.3.1 for headings also addresses some aspects of Guideline 2.4.
Guideline 2.5: Input Modalities
I think that this needs a note or caveat - closed systems may not support 3rd party input devices due to architectural or security reasons, and so would be excluded.
I think that this needs a note or caveat - closed systems may not support 3rd party input devices due to architectural or security reasons, and so would be excluded.
They may not allow 3rd party ones, but the actual system may provide different input modalities yet expect only a specific input to be used for a specific control/task, and it should instead allow for all its provided modalities to be used
Plus the SCs around pointer gestures, pointer cancelation, reliance just on motion (if other inputs are available), target size, concurrency are all equally valid in the context of even closed systems that provide pointer input mechanisms etc
@pday and @patrickhlauke I think some confusion is being introduced because the WCAG2ICT Note includes the intent for the various guidelines and Success Criteria - completely unchanged. WCAG2ICT is simply analyzing the actual text of the Guideline to see if it is applicable as-is, or if there needs to be any clarification of the Guideline text due to the use of web-based language. The scope of the work is not to modify or clarify the intent - even if it is written in web-based language. Any specific SCs that have caveats for non-web software or non-web documentation will be handled with the specific SC (soon to come work).
I added Guideline 2.5 in PR #67 per our meeting discussion on 1 December. The changes for guidelines 2.3 and 2.4 will automatically get incorporated once we get the includes from WCAG working in the markdown files.
Oops, forgot this is going to AG WG for review - the next step. Reopening.
AG WG has a survey open until 9 March with AG WG survey results discussion at a TBD future date (after CSUN conference).
Complete and merged. Approved in the AG WG meeting on 21 March 2023.