First Set of Outcomes

[rachaelbradley]

We have a subgroup that is working on an initial outcome (Visible keyboard focus) but when they are done, we'd like to set up 5-6 subgroups to work on a first set of outcomes.

Based on discussion in the 6 February Meeting, the group should include a diverse, representative set of outcomes that includes a mix of guidance covered in WCAG 2.2 and gaps in WCAG 2.2.

Please propose and vote on a set of outcomes for the first set of subgroups that meets these criteria:

• thumbs up for support,
• thumbs down for concerns,
• eyes for neutral or watching)

Please note: This thread is to select the set of outcomes for work and not to start working on those outcomes.

[rachaelbradley]

(Chair hat off) I'm suggesting the following set because, along with Visible keyboard Focus, I think it will give us a mix of old and new; qualitative tests, quantitative tests, and assertions; discussion around accessibility supported, and guidance across various categories and user needs.

1. Section Labels: Sections of content have clear visual and programmatic labeled
2. Implied meaning in figurative language: Explain figurative language or non-literal language such as jokes, sarcasm, hyperbole, metaphors, similes, and idioms.
3. Adjust Color: Users are able to adjust color schemes
4. Haptic stimulation: Protects users from haptic over-stimulation
5. Keyboard Only: All functionality can be performed through the keyboard interface only, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

[alastc]

Perhaps as part of this we could split the Section Labels guideline? Once you break down the methods, there are some which don't apply visually, and some which don't apply to code.

Apart from that, it seems like a wide range for 5 outcomes!

[GreggVan]

+1 to @chaals comments — or at least his bottom line (I had trouble following some of it) To make things clearer (hopefully — this is a topic that it is easy to get confused by) Keyboard interface - does not refer to a physical keyboard - it is the interface the software gets keystrokes from the OS - it is critical to accessibility by many disabilities - and mousekeys is NOT an equivalent - nor is voice or pointing or any other technique. (They are ALL good things for other PWD and for some people who migh use an AT that contrrols content through the keyboard interface - but they are not useable by all who need keyboard interface access. so — keyboard interface remains a critical and fundamental requirement for accessibility — other things are good supplements but not substitutes for keyboard interface access – mousekeys does not count as “operates with a keyboad interface” because it come to the program through the mouse interface, not the programs “keyboard interface” Best Gregg

…

On Feb 14, 2024, at 6:14 PM, chaals ***@***.***> wrote: I am fundamentally saying: the exception given for the requirement, based on the input being to provide path-based information, makes no sense. there are different problems that can arise with a keyboard interface, some we address and some we should explain better. But I'm not convinced they justify not providing a keyboard interface. I'm proposing that we still say "mouse keys doesn't count" because in general it doesn't. In more detail... A "keyboard interface" is some mixture of two things: A technical system that uses particular inputs An interaction design that doesn't assume a pointer, but does assume a large number of distinct actions (all the different keys) Using Mouse keys is generally (but not always) an example of my second problem case - pointer-based interfaces are rarely designed to be efficient when driven by a keyboard. Using mouse keys to draw a path in a graphics package is actually a pretty sensible thing to do. A "native" keyboard interface to draw a path generally works like mouse keys. But using mouse keys to swap between the control points used to draw a cubic curve isn't sensible - these are more like a set of options in a menu of things to do to a curve, so e.g. tabbing to the "curve options", being able to switch between the control points in sequence, and then being able to move them either by entering coordinates as text or by moving them around (in a way that's effectively mouse keys) makes more sense. Meanwhile, moving between multiple controls in a flight simulator using mouse keys is a terrible design, and in most cases the control itself shouldn't be operated with mouse keys. Movement controls in games are generally not pointer-based - something like arrow keys or a block of keys like qweasdzxc (on a qwerty keyboard - there needs to be adaptation for an azerty keyboard or any other variant) are used in a way that's like a self-centering joystick. Many pointer-based interfaces for controlling motion are just trying to figure out how to make a mouse-friendly version of something that actually started out being a keyboard- or joystick-based interface, and aren't even a very good control system. — Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXV6NJY5JYMZ2Y2ZUNDYTVVPJAVCNFSM6AAAAABDI42AX2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINZUGI2TK>. You are receiving this because you are subscribed to this thread.