Wcag: ARIA authoring pratices design pattern to conform WCAG ?

[goetsu]

Hi,

I would like to have the WG opinion regarding design pattern listed in ARIA authoring practices regarding conformance to WCAG

I think there is different cases to consider :

1. someone implementing a component corresponding to a design pattern but without following design pattern at all (for example tabs without tabs design pattern like https://codepen.io/jeffsmith/pen/mPByya/ )
2. someone implementing a component corresponding to a design pattern, following the role state and property described in the corresponding design pattern but not following the described keyboard interaction (while still making it usable with keyboard for example a tablist where each tab can be reach by tab key instead of arrow key)
3. someone implementing a component corresponding to a design pattern, following the described keyboard interaction but not the role state and property described in the corresponding design pattern (for example a tablist without role tablist or tab but simply a list of buttons that can be focused with arrow keys only and with the currently selected one with aria-current="true")

[patrickhlauke]

my personal take (depending on circumstance / specific implementation of course) would be:

1. not necessarily a WCAG failure
2. not necessarily a WCAG failure (as 2.1.1 Keyboard doesn't say anything about specifically how a component should follow standard behaviours, just that it be "keyboard accessible"), unless it demonstrably breaks when AT is running (e.g. if keyboard + screen reader users simply can't operate it because it relies on keys that are consumed by the screen reader normally, so are not passed to the script, when AT is running)
3. most likely a failure of WCAG 4.1.2 Name, Role, Value

[patrickhlauke]

addendum for 2: however, i would generally (depending how far they stray from the expected interaction pattern) add a strong suggestion/best practice recommendation in a report, explaining that it would improve usability and avoid confusion for users if they stuck to at least the non-optional commands outlined for a pattern

[awkawk]

I agree with Patrick. I think that the ARIA design patterns are like WCAG techniques in the that they represent a recommended way to achieve a result but not necessarily the only way to do so.

Not following the design patterns will mean that the likelihood of having good Accessibility Support is decreased, increasing the chance that there will be problems for assistive technology users (and increasing the burden on the developer to ensure that those problems don't exist).

For keyboard access, like Patrick says, if you break the expected keyboard interaction model enough then users will be less likely to know how to interact with the control. You could make the case that you documented the keyboard shortcuts, but I think that there is a point where you would have no evaluators willing to sign off on an approach. If each tab was tabbable instead of arrowable, people can adapt, but if you decided to use the "8" character to move between tabs, no one would support that.

So, if someone said that they were creating a rule inside their company to always follow the design practices, I would say that is a good idea for consistency and ease of development, testing, and use. But if someone said that we should create a rule in an accessibility evaluation tool which required use of the ARIA best practices to pass a Success Criteria, I wouldn't support that for WCAG 2.x.

[scottaohara]

Also worth referring to the sections from the Authoring Practices note of:
Browser and Assistive Technology Support
Mobile and touch support

Recommendations of how to build something, and even the recommendations are noted as having potential support gaps. Always be testing :)

[mraccess77]

Personal opinion aligns with Patrick and Andrew.

1. someone implementing a component corresponding to a design pattern but without following design pattern at all (

As long as the same information such as visually communicated currently selected tab, etc. is communicated programmatically it could pass. Not optimal always. This is how things were prior to ARIA.

2 someone implementing a component corresponding to a design pattern, following the role state and property described in the corresponding design pattern but not following the described keyboard interaction (while still making it usable with keyboard for example a tablist where each tab can be reach by tab key instead of arrow key)

Likely yes, but with accessibility support by assistive technology and documentation of keystrokes and some reasonableness of choices.

3 someone implementing a component corresponding to a design pattern, following the described keyboard interaction but not the role state and property described in the corresponding design pattern (for example a tablist without role tablist or tab but simply a list of buttons that can be focused with arrow keys only and with the currently selected one with aria-current="true")

More likely a fail if the role doesn't match the keyboard pattern as this will likely have accessibility supported implications.

Even if content can be used if it's not structured in way that is easily understood by users either keyboard only or AT users -- you may still have user frustration and users leaving your site or users who feel that it is not accessible and seek litigation or change. So there is some business and other risk associated with doing things in a way that is not easily understood.

[DavidMacDonald]

I agree with John Patrick and Andrew. The ARIA techniques are a tremendous service to the community, but there can be gaps and I've seen legal cases where a legal team failed a tabbed interface where the tab key moved the user across the tabs, for not being "arrorwable" citing aria practices.

They are great techniques and most work well but there are still many gaps especially when morphing to touch environments and they are not vetted by the AG.

[patrickhlauke]

I've seen legal cases where a legal team failed a tabbed interface where the tab key moved the user across the tabs, for not being "arrorwable" citing aria practices

Hopefully somebody pointed out to them that ARIA practices are not normative, but "just" best practices (and in some cases only document one of many possible approaches)

[awkawk]

Proposed WG Response:
The discussion on this issue captures the essence of the WG view on this question - that ARIA best practices represent best practices, but that they are not normative and do not automatically trigger a failure of any SC if not followed.

[mbgower]

I'll note that I've been concerned lately that keyboard operation that fails to follow conventions does not technically fail 2.1.1 (even though I personally will fail undocumented custom keyboard operation). In the (distant) past guidance from MS, etc. determined expected interaction for any given component. For the web, the APG is approaching that baseline measurement. I think we should consider creating at least a Sufficient Technique where following APG keyboard interaction documentation meets 2.1.1.

[alastc]

The proposed response was approved by the working group, so I'm closing this issue.

@mbgower - I've added a potential technique to the tracking spreadsheet.