Keyboard with AT #62
Comments
|
I think we could roll the advice of the techniques into another SC and close this, given that 2.1.1 covers almost all this. We could revisit keyboard input for Silver. |
|
Signed up as SC Manager |
|
I think guidance to authors on how to effectively and safely use keyboard shortcuts is useful. The techniques listed are examples of some of these, but as David notes they could be worked into 2.1.1. This SC seems to be covered by conformance requirement 4. Only Accessibility-Supported Ways of Using Technologies.
Do we feel it is necessary to more explicitly capture such requirements in SC? |
|
I agree with the preceding comments. In addition, step 2 of the proposed testing procedure is problematic, and it raises concerns about the entire proposal. Suppose I'm an author and I test this with my ready to hand assistive technology that remaps certain keystrokes, so it passes. Then users access the content with different assistive technologies that map keystrokes differently, so it raises difficulties for them. You might claim that I should have chosen key combinations compatible with the users' assistive technologies, but, if that's how the requirement is to be interpreted, I would then need to know how every AT available that can be used with the content maps keys. What then happens if the user's operating system is configured for a different locale/keyboard layout from mine? Many ATs (screen readers in particular) provide bypass keys to work around keyboard conflicts, so I question whether this could be a high-priority issue in any case. Surely the better solution is on the AT side, with some non-normative guidance about how to choose keyboard bindings appropriately when implementing applications. |
|
Agree that this would logically make sense to be added somehow to existing keyboard SC (likely only needing an explicit mention in understanding, plus technique). Context for having this as separate SC was that originally updates/additions to WCAG 2.0 SCs were not on the table... |
|
Thanks for that clarification, Patrick. I'd be hopeful that modifications to the existing 2.0 SC that do not alter their essential character but extend the guidance to encompass current technology would be possible. I realize there are real considerations not only for backward compatibility but also for reducing complexity for reporting purposes. |
|
I think that this can be retired. It is already covered there with no need for any modifications to the normative WCAG 2.1.1 SC. The modifications would be limited to the non normative Understanding DOC text for 2.1.1 There is a further danger in proceeding with this SC for WCAG 2.1. This SC will be perceived as a new requirement in 2.1 and jurisdictions may falsely believe that WCAG 2.0, SC 2.1.1 does not apply when AT is running. |
|
Unless there's disagreement/opposing views, @kwahlbin can you mark this as retired/closed? |
|
Putting this under accessibility supported seems like a stretch to me -- would the case of not using proper ARIA roles to tell screen readers that they are in a particular control be an issue under SC 4.1.2? Reliance on other keyboard shortcuts that were conflicts could also be an issue unless the keystrokes could be remapped or there was a way to pass them through. However, passing keys through is not an optimal solution that shouldn't be relied upon for standard operation. A current example is an element that doesn't have a click event but has a keydown and a mousedown event. I see this a lot. It is keyboard accessible and is mouse accessible -- but screen reader users are forced to press control+enter or pass through enter or change a setting in their AT. I consider that a misuse and a violation -- but perhaps it's not a strict violation of the current WCAG. |
Yes, if the name, role, state, and changes to any of these are not reported, it currently fails 4.1.2 |
I was thinking reported but not correctly. |
I'd currently fail this under 2.1.1, but you're right the current wording of 2.1.1 (and the use of "keystroke" in the definition of keyboard interface, as discussed in the other SC thread #63 (comment)) make this ambiguous |
If any of these Name, Role, Value are incorrect, or updated incorrectly the content fails 4.1.2 |
|
@patrickhlauke Based on the comments on the working group call on Jan 31, it is not off the table to make changes to 2.1.1. Are there suggestions on what change you would see for 2.1.1? |
|
@kwahlbin @patrickhlauke Guys, if you think this SC may indicate a need for a more fundamental change to 2.1.1 - we'd like to hear it. |
|
This is related to w3c/wcag#67 Device Sensors - both may indicate a needed change in SC 2.1.1 |
Just a note that when/if we get around to modifying 2.1.1 for matters already discussed here and in places like w3c/wcag#63 (Touch with AT) and w3c/wcag#67 (Device Sensors) , some language around avoiding keydown and mousedown can be incorporated into 2.1.1, and we should consider creating some Failure Techniques. See the Testability and Techniques sections of w3c/wcag#59 Pointer as a starting point. |
|
@kwahlbin @joshueoconnor @awkawk @patrickhlauke I would suggest this Issue be closed and updates to 2.1.1 related to this proposed SC be pursued through Issue w3c/wcag3#199 w3c/wcag created by @DavidMacDonald which contains suggested wording that could be added to Understanding Doc for 2.1.1 to cover this. I've also added @mbgower comment above to Issue w3c/wcag3#199 w3c/wcag |
|
@marcjohlic I have asked @awkawk and @joshueoconnor to clarify what can and cannot be done. The decision was made over a year ago not to make any significant changes to the existing WCAG 2.0 SCs. The taskforce created separate SCs for this reason. If it is decided that significant changes to 2.1.1 will be done, we must look at all of these together and not one at a time as this is more complex than it may appear on the surface. |
|
@kwahlbin OK, yep I agree. To clarify, I was only suggesting "closing" this Issue 62 as far as FPWD was concerned, but then revisiting the topic afterward via that Issue 262 - as the group takes another look at updating existing WCAG SC - post FPWD - per the recent survey and AWK's note the other day: |
Current versions of SC and Definitions
SC Shortname
Keyboard with AT (that remaps key input)
SC Text
All functions available by keyboard are still available by keyboard after accessibility-supported assistive technology that remaps keystrokes is turned on.
Suggestion for Priority Level (A/AA/AAA)
Level AA
Related Glossary additions or changes
N/A
What Principle and Guideline the SC falls within.
Principle 2, new Guideline "Inputs with Assistive Technology"
Description
It is not always possible for users to activate arbitrary keys on a keyboard, as these may be reserved for commands to operate an assistive technology. Assistive technologies may intercept key presses before they reach the content (e.g. JavaScript on a webpage), except in very specific circumstances (such as when a text entry field receives focus).
As such, authors must not assume that users are able to successfully activate any particular key controls arbitrarily.
This success criteria would apply to the assistive technology that is accessibility-supported and remaps the keyboard.
Benefits
This ensures that all users can operate the functionality when the keyboard is used with the assistive technology.
Testability
Techniques
Content should not rely on user's ability to arbitrarily press keys (e.g. don't add a
keydown/keyup/keypresshandler simply to the<body>); ensure functionality hangs off of focusable controls; rely onfocus/blur/clickevents; can listen for key presses, but only when focus is in a traditional input/text entry field (as there AT doesn't interfere with key presses) OR userole="application"(where you indicate to AT that you will handle all keyboard input directly, suppresses reading keys etc.)The text was updated successfully, but these errors were encountered: