Clarification for applicability of F15 technique & 4.1.2

[scottaohara]

Adds note to clarify that the F15 technique is only about exposing custom controls to the accessibility api of a platform, and that keyboard accessibility (per the logged issue) are not in scope for 4.1.2 - they are covered by their own SCs.

closes #3516

[detlevhfischer]

Substantially fine, one or two links in section Resources might better be removed.

[mraccess77]

I'd mention for the record that improper roles could lead to the control not working with a screen reader and other technology via the keyboard or other input - e.g. programmatic access to activate the control by assistive technology that uses API. While I agree that WCAG only requirement keyboard interface access and not specific keystrokes accessibility supported issues can arise with the keyboard and assistive technology when the API information is not correct.

[mbgower]

I'd mention for the record that improper roles could lead to the control not working with a screen reader and other technology via the keyboard or other input - e.g. programmatic access to activate the control by assistive technology that uses API. While I agree that WCAG only requirement keyboard interface access and not specific keystrokes accessibility supported issues can arise with the keyboard and assistive technology when the API information is not correct.

I agree with this, but the 'opposite' is unfortunately also true; the role can be correctly assigned and the author can also implement novel keyboard interaction which causes users of assistive technology to have challenges operating via the keyboard. There is a requirement to be accessibility supported, but how failures of this are established and reported have never been adequately addressed, IMO. It certainly exceeds the requirements of Name, Role, Value alone.

[patrickhlauke]

the 'opposite' is unfortunately also true; the role can be correctly assigned and the author can also implement novel keyboard interaction which causes users of assistive technology to have challenges operating via the keyboard. There is a requirement to be accessibility supported, but how failures of this are established and reported have never been adequately addressed, IMO

yeah, this goes back to the discussion we had around 2.1.1 Keyboard - feels like it's more to do with 2.1.1 plus "accessibility supported" / non-interference, to some extent (but as you say, never really fully bottomed-out where a potential failure may lie, and it falls between the gaps)

[ljoakley]

Can we use another description than "disclosure widget ", this is not a very descriptive term for a non technical user.

[mbgower]

Can we use another description than "disclosure widget ", this is not a very descriptive term for a non technical user.

@ljoakley "disclosure" is a fairly common term used to describe something that reveals more information. For instance, there is a disclosure pattern in the ARIA Authoring Practices Guide.

However, I have swapped in a specific example of a disclosure widget, an accordion. There are many of disclosures widgets, but hopefully this adds clarity.