ARIA WG – 01 April 2021

jcraig: Apple platform has a lot of accessible dataviz functionality: chart summary, trend, outliers, indices, and audio graphs... Web API for this was on my to-do list... but I'm out next week. jamesn: okay no deep dive next week.

1.2 PR - steps needed - testable statements

jamesn: how can we help?

<joanie> https://github.com/w3c/aria/wiki/1.2-Non-editorial-features-and-other-changes

joanie: when through these items... written locally, but have some questions:

one specific test question before the request:

<joanie> Do we expect implementations to change to check for this and stop exposure? (If so, some user agents might give pushback. If we don’t expect this, then what is there to test? If it’s validators, that is outside the scope of WPT.)

joanie: does this fall under the category of validators to flag? or are we demanding UAs change?

jamesn: IIRC, for non-global attrs, spec says must not expose

<jamesn> "User agents MUST ignore non-global states and properties used on an element without a role supporting the state or property; either defined as an explicit WAI-ARIA role, or as defined by the host language WAI-ARIA semantic matching an appropriate WAI-ARIA role. For example, the aria-valuetext attribute may be used on a progressbar."

<jamesn> https://w3c.github.io/aria/#state_property_processing

jcraig: I think it's reasonable for Firefox to expose DOM properties like all aria-* attrs. as long as they don't expose it to the non-aria parts of the tree, e.g. not a SELECTED prop on an element that doesn't supports aria-checked, but okay to expose the raw DOM attr aria-checked

Action: joanie to write a test and discuss with Mozilla

joanie: several were deprecated as globals... test should be N/A, correct?

[scribe apologies. fighting with client UI updates instead of scribing]

joanie: using core AAM to test ARIA... don't have a better way to get a platform-agnostic role or prop

joanie: additionally for exit criteria we need these in core aam, so forced to duplicate some tests before landing in WPT

1.3 FPWD - steps needed

jamesn: working through authoring practices for 1.3. should have FPWD after those?

struggling how to do aria-braillelabel and aria-brailleroledescription... don't want authors to use accidentally

"sld" example in spec

jcraig: braille short-hand should make sense in context... "btn" button commonly understood, but "sld" as slide would only be clear in the context of a web slide deck web app

jamesn: propose adding strong language advising against using them at all

Action: jcraig to dig for recent "aria-braille*" thread and share the text

privacy statement

jamesn: new draft

<jamesn> https://raw.githack.com/w3c/aria/jnurthen/issue1371/index.html#privacy-and-security-considerations

<jamesn> In accordance with Web Platform Design Principles, this specification provides no programatic interface to determine if information is being used by Assistive Technologies. However, this specificaton does allow an author to present different information to users of Assistive Technologies from the information available to users who do not use Assistive Technologies. This is possible using many features of the ARIA specification, just as this

<jamesn> is possible using many other parts of the web technology stack. This content disparity could be used as a device fingerprinting method for users of Assistive Technologies.

jcraig: seems reasonable... Sarah convinced me last week that "device fingerprinting" was okey to include

no objections to taking this to PNG

Action: jamesn to take privacy text to PNG

[onboarding](https://github.com/w3c/aria/issues/1401)

<jamesn> https://docs.google.com/document/d/1eOuxryD506tFc3ckGHclrluhJoCVvdb8FSLoTqaU8ZY/edit

jamesn: Jemma was taking this item... she was creating a Google Doc

jamesn: please add to it as necessary

[Should all roles participate in the name calculation of ancestors in name from content (Step 2H)](https://github.com/w3c/accname/discussions/113)

jamesn: joanie

joanie: I am not a web author, but I think consensus is that this is an example of bad authoring....

confirmed with Leventhal

Bryan: I agree this is a bad authoring practice... would not want to imply its acceptable b/c it causes so many issues

jamesn: should we add an author MUST NOT in accname or aria specs?

or UA MUST NOT?

jamesn: I linked in the issue discussion to a list of what roles the browsers do or do not expose this for

Bryan: no explicit rule against it , but generally not included

sarah_higley: how would this affect live regions?

Bryan: would this cause a live region change and trigger an announcement?

Bryan: depends on the live region re: aria-atomic/aria-relevant

joanie: figure out consensus and comment in the issue https://github.com/w3c/accname/discussions/113

jamesn: browser consensus should be enough to change it in the spec

jamesn: need to look at whether "name from contents" is incorrect

Bryan: I have... depending on the role. safe to include static. ex: link includes img role or figure, or math

if it's a static element role (e.g. no link with child slider)

for example, link in HTML can contain table... if you don't allow name from content in table, those would not have a name

<joanie> https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/modules/accessibility/ax_object.cc;l=5214

jcraig: spec should not disallow UAs from trying to make the most of bad authoring examples... Could have an authoring recommendation to not do something bad, but UAs need to work regardless

joanie: I think this works in Firefox, but not Chrome (verify scribe please?)

<joanie> Chrome does NOT descend a table for name from contents.

<joanie> Firefox did not USED to descend a table for name from contents. I believe I was the one who changed that in Firefox.

jamesn: over time... need an action

Action: Bryan to add to accname spec

– DRAFT –
ARIA WG

01 April 2021

Attendees

Meeting minutes

[New Issue Triage](https://bit.ly/39qJPpY)

[New PR Triage](https://bit.ly/3m4ptIh)

[Meaty topic for next week](https://bit.ly/2PFjeP8)

1.2 PR - steps needed - testable statements

1.3 FPWD - steps needed

privacy statement

[onboarding](https://github.com/w3c/aria/issues/1401)

[Should all roles participate in the name calculation of ancestors in name from content (Step 2H)](https://github.com/w3c/accname/discussions/113)

Summary of action items

Diagnostics