Discuss potential for additional webdriver accessibility properties beyond computedlabel and computedrole

[cookiecrook]

I took an action to enumerate the full list of what we thought might be needed as new webdriver properties to complete more extensive browser internals accessibility testing in WPT. These are not name proposals. They are just enough to start a discussion of the list of attrs that can't easily be tested with existing accessors.

It's also worth noting that:

• some (hidden/isIgnored for example) are higher priority due to testing difficulty and interop impact on users/authors
• some of these are very low priority due to stability or low user impact
• many of these likely won't be needed in 2023

Tree/Parent/Children

• Consider accessibilityparent/accessibilitychildren in webdriver #21

Boolean or Token values where there is a host language equivalent and potential conflict resolution

• checked (e.g. <input type="checkbox" checked> or <div role="checkbox" aria-checked="mixed">)
• pressed (e.g. toggle buttons)
• selected (menu items, select options, listbox items)
• required (native and aria)
• invalid (native and aria)
• disabled (native and aria)
• readonly (native and aria)
• expanded (aria-expanded, summary/details, more?)
• orientation (aria-orientation or native orientation of scrollbar, slider, etc)

Same but lower priority IMO

• multiline (<textarea> or <div role="textbox" aria-multiline="true" contenteditable="plaintext-only">)
• multiselectable (<select multiple> or aria-multiselectable="true")

String values where there is a host language equivalent and potential conflict resolution

• placeholder (native and aria)
• errormessage: Is element.ariaErrorMessage sufficient?

Others where there is a host language equivalent and potential conflict resolution (these first two both happen to be integers, but some may include other types, see value props in the next section)

• level (e.g. <div role="heading" aria-level="2"> or <h2>)
• colspan/rowspan (native and aria)

Those that are or may end up in AccName

• computed description (we already have computed label and role in webdriver. Note: ARIA is considering adding "value description" to the accname spec, so including those here too.)

• value/aria-valuenow

• value/aria-valuetext

• max/aria-valuemax

• min/aria-valuemin

• step (IIRC there is an issue for aria-step?)

Related to hidden, rendered/unrendered, inertness, and modality?

• hidden (aria-hidden, unrendered, inert, isIgnored and more?)
• modal (aria-modal or showModal from dialog API?)

Others

• aria-owns. implementations differ, but this would most likely be covered by parent/children accessors unless there is an implementation objection to https://webkit.org/b/241694 ... IMO, the edge cases are still unspecified or under-specified.
• busy: should the busy state cascade to its descendants? If not, this may not be needed, because element.ariaBusy should suffice for the current element. Might need an ARIA issue to determine the answer.

Notes

I did not include any of the other ARIA attributes (e.g. aria-braillelabel) where I thought the ARIA attribute was the only way to set or get the value, as those should be passed through directly. In theory, adding webdriver getters for those would be redundant because of ARIA attribute reflection. This includes the element object references like aria-controls, with the exception of aria-owns as called out above.

If I missed any, please comment and I'll try to update the OP.

[cookiecrook]

WebKit's inspector protocol for AccessibiltyProperties (for UI exposed in WebKit Web Inspector > Node > Accessibility) may be a good starting point.

[cookiecrook]

Agenda should be to discuss which group should own what will likely result in some spec change... WICG AOM seems like the obvious starting point, even if potential changes end up in BTT WG WebDriver, WHATWG TestUtils, or some new ARIA WG deliverable.

[cookiecrook]

Group agreed to pass this over to AOM. I will file an issue there and then close.

[cookiecrook]

• Computing the Accessible Backing Node, or a similar test-only interface WICG/aom#197