[wg/aria] Accessible Rich Internet Applications Working Group Recharter

[daniel-montalvo]

New charter proposal, reviewers please take note.

Charter Review

Accessible Rich Internet Applications:

diff from charter template

If applicable:
diff from previous charter

chair dashboard

What kind of charter is this? Check the relevant box / remove irrelevant branches.

• New

• New WG
• New IG
• If this is a new WG or IG charter request, link to Advance Notice, and any issue discussion:

• Existing

• Existing WG recharter
• Existing IG recharter
• If this is a charter extension or revision, any issue discussion:

Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. Also add a "card" for this issue to the Strategy Funnel.

Communities suggested for outreach:

Known or potential areas of concern:

Where would charter proponents like to see issues raised? (this strategy funnel issue)

Anything else we should think about as we review?

Note: proposed chairs should be copied @spectranaut @jnurthen on this issue.

[svgeesus]

Any reason not to request horizontal review of the proposed charter?

[plehegar]

SVG-AAM has to be explicitly a deliverable of the WG. At the moment, ARIA is just meant to collaborate with the SVG WG, not to deliver it. Shouldn't we list at the same level as the HTML AAM, and add that it is a joint deliverable?

cc @iadawn

[daniel-montalvo]

@plehegar

SVG-AAM is now explicitly added as a deliverable.
https://w3c.github.io/charter-drafts/2024/aria-charter.html

[simoneonofri]

Hi @daniel-montalvo

I read the Security Considerations of the various deliverables. I noticed that it often says:

This specification introduces no new security considerations.

Could you explain the reasoning behind these statements? Not because I think it is wrong but because I would like to understand.

Thank you in advance :)

Simone

[daniel-montalvo]

Hi @simoneonofri

There was a discussion about Privacy and Seccurity issues that the ARIA spec could introduced back in 2020. For background, see
Detectability of assistive technologies

The group reached an agreement that this was more a privacy issue, and that it could happen in ARIA just as it could happen with other technologies.

As a conclusion, the following text was added in the privacy section of the ARIA spec.

In accordance with Web Platform Design Principles, this specification provides no programmatic interface to determine if information is being used by Assistive Technologies. However, this specification 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 is possible using many other parts of the web technology stack. This content disparity could be abused to perform active fingerprinting of users of Assistive Technologies.

Because changes in the ARIA specs only add, qualify, or deprecate the use of roles, atrributes, and properties, the group believes that these changes introduce "no new security considerations".

Is there anything else you are missing for the security sections?

[simoneonofri]

Hi @daniel-montalvo,

Thank you very much for the clarification and context.

Two potential reflections in the area of security:

• If the attributes/element can be used to trigger events on JavaScript (e.g., as the onlick attribute can be) then it might make sense to specify that there is an increased attack surface for e.g. Cross Site Scripting.
• Another issue - but it's a generalized problem still found even on HTML5 elements/attributes in 2024 - is that any ant-XSS blocklist filters (and blocklist in fact are not a very good security practice) do not also include WAI-ARIA attributes/elements that can be used to escape.

Thank you,

Simone

[ruoxiran]

no comment or request from APA.

[daniel-montalvo]

Hi.

Thanks for sharing your thoughts.

• If the attributes/element can be used to trigger events on JavaScript (e.g., as the onlick attribute can be) then it might make sense to specify that there is an increased attack surface for e.g. Cross Site Scripting.

None of these attributes are used to trigger JavaScript events.

• Another issue - but it's a generalized problem still found even on HTML5 elements/attributes in 2024 - is that any ant-XSS blocklist filters (and blocklist in fact are not a very good security practice) do not also include WAI-ARIA attributes/elements that can be used to escape.

That sounds like something that will affect more specs than just ARIA. I am open to following along through your advice on how to write security considerations and update ARIA ones later on based on this (and potentially other) thoughts.

[himorin]

no comment or request from i18n

[plehegar]

PING is fine

[daniel-montalvo]

Closing. Review is complete. TAG does not intend to review this.

[himorin]

reopening this, this is not just for horizontal review, but through whole chartering period.

[plehegar]

I submitted a pull request. See w3c/charter-drafts#589 .

In addition:

• In external organization: "IMS Global Learning Consortium" does no longer exist.
• Charter history hasn't been updated to reflect the draft charter

[plehegar]

Note that, in my pull request, I removed the Web Platform WG from the coordination section since that group does no longer exist. For HTML, thew coordination with the WHATWG is already listed.

[svgeesus]

Thank you @plehegar for spotting these issues, which I came here to report, and also for a PR to fix them.

In general this rechartering has not been done well. Instead of starting from the current charter template and adding up-to-date info, it seems to be a light warming-over of an existing charter. This produces a lot of extra work for horizontal reviewers, for TiLT, and (if everything is not fixed) for the AC as well.

[siusin]

See w3c/charter-drafts#597.

Wonder if the ARIA WG would consider adding some specific description of their work about the HTML Accessibility API Mappings spec and the ARIA in HTML spec in the Scope section.

[svgeesus]

In addition:

• In external organization: "IMS Global Learning Consortium" does no longer exist.

• Charter history hasn't been updated to reflect the draft charter
  I see these have not been fixed

[daniel-montalvo]

Thanks @svgeesus

* In external organization: "IMS Global Learning Consortium" does no longer exist.

w3c/charter-drafts#599 fixes this

* Charter history hasn't been updated to reflect the draft charter

Do we have guidance as to how we should be indicating this?
Should this be in the last row of the Charter History table? Somewhere else?

[plehegar]

• Charter history hasn't been updated to reflect the draft charter

Do we have guidance as to how we should be indicating this? Should this be in the last row of the Charter History table? Somewhere else?

Yes please. Add row in the table to note the substantial changes.

[svgeesus]

1. Under Success Criteria, while I do appreciate copying some text from CSSWG charter: Success Criteria, you should change "module" to "Specification" because CSS WG has one deliverable with many modules while ARIA does not.

2. The charter template has

Consider adding this clause if the Group does not intend to move to REC: All new features should have expressions of interest from at least two potential implementors before being incorporated in the specification.

This has been removed, and yet nine deliverables are marked (living standard). The sucess criteria uses only the wording about moving to Proposed Rec, which only applies to two deliverables.

3. The template has

Consider adopting a healthy testing policy, such as: To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations should have tests. Testing efforts should be conducted via the Web Platform Tests project.

That text has all been removed. Do ARIA specifications not need tests? Is WPT not suitable for ARIA tests?

4. The template has

This (Working|Interest) Group expects to follow the TAG Web Platform Design Principles.

which has been removed. Does ARIA not intend to follow those principles? Or do they not apply?

5. In Communication the link to Accessible Rich Internet Applications Working Group home page. goes to https://www.w3.org/WAI/about/groups/ariawg/ but should instead go to https://www.w3.org/groups/wg/aria

By the way, I notice the change from "Each specification should contain sections detailing all known security and privacy implications" to "Each specification should contain separate sections detailing all known security and privacy implications". Nice addition, which I have also made to the template

[daniel-montalvo]

thanks @svgeesus for your detailed review and helpful comments. w3c/charter-drafts#601 takes care of them. See below for explanations and one additional question.

1. Under Success Criteria, while I do appreciate copying some text from CSSWG charter: Success Criteria, you should change "module" to "Specification" because CSS WG has one deliverable with many modules while ARIA does not.

Done.

2. The charter template has

Consider adding this clause if the Group does not intend to move to REC: All new features should have expressions of interest from at least two potential implementors before being incorporated in the specification.

This has been removed, and yet nine deliverables are marked (living standard). The success criteria uses only the wording about moving to Proposed Rec, which only applies to two deliverables.

Added back.

3. The template has

Consider adopting a healthy testing policy, such as: To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations should have tests. Testing efforts should be conducted via the Web Platform Tests project.

That text has all been removed. Do ARIA specifications not need tests? Is WPT not suitable for ARIA tests?

The ARIA WG does have more and more test under WPT now, but there are still some tests that need to be conducted manually, especially when it comes to testing Accessibility API mappings. The tests are in WPT specific accessibility ssub-folders, but it is not possible at the moment to conduct them in WPT. Work is currently happening for this to be possible in the future though. I'd be more comfortable if we changed "conducted via" to something softer like "described in", "reported in", or "declared in". I go with "declae in" in the PR for now, happy to discuss other alternatives.

4. The template has

This (Working|Interest) Group expects to follow the TAG Web Platform Design Principles.

which has been removed. Does ARIA not intend to follow those principles? Or do they not apply?

Added back.

5. In Communication the link to Accessible Rich Internet Applications Working Group home page. goes to https://www.w3.org/WAI/about/groups/ariawg/ but should instead go to https://www.w3.org/groups/wg/aria

By the time this was put together in late 2023 it was not clear where this should be pointing to. WAI has discussed this further and you are right, we should be pointing to the official W3C WG homepage. Done.

By the way, I notice the change from "Each specification should contain sections detailing all known security and privacy implications" to "Each specification should contain separate sections detailing all known security and privacy implications". Nice addition, which I have also made to the template

[daniel-montalvo]

• Charter history hasn't been updated to reflect the draft charter

Do we have guidance as to how we should be indicating this? Should this be in the last row of the Charter History table? Somewhere else?

Yes please. Add row in the table to note the substantial changes.

Added table row in 11.1 and detailed changelog in 11.2

[svgeesus]

What does

PDF Accessibility API Mappings 1.0 (living standard)
TBD

mean? I know that means To Be Determined, but shouldn't it say "No Draft"?

In general the charter is looking much better now.

[plehegar]

one minor nit: the change log section is meant to contain the changes after the charter is approved (there is an HTML comment in the charter template explaining this). The section could be left as-is for the AC Review but will need to be emptied once the change is approved, to avoid future confusion.

[daniel-montalvo]

@svgeesus

w3c/charter-drafts#605 fixes this.

[svgeesus]

w3c/charter-drafts#605 fixes this.

That gets rid of the TBD. But it should also say:

Draft state: No draft

[daniel-montalvo]

@svgeesus
Added "no draft" and milestone at w3c/charter-drafts#606

[daniel-montalvo]

Charter available in W3C space at
https://www.w3.org/2025/01/aria-charter.html

[npdoty]

Since the privacy review was completed, we've chartered a Privacy Working Group taking over the work from PING (Privacy Interest Group). If editorial changes are still accepted, we could make that update. But no objection or concern -- I'm confident no one would be long confused by the older link.

[daniel-montalvo]

Thanks @npdoty

#622 should fix this.

@plehegar I think this passes for minor changes under Managing changes to charters after review and we could include it.

However, if this is going to trigger another Call for Review, I would prefer not to. include #622 Otherwise I'd be happy to. I assume at some point https://www.w3.org/groups/ig/privacy/ will clearly indicate that work is now happening at https://www.w3.org/groups/wg/privacy/

[daniel-montalvo]

See Charter questionnaire results at https://www.w3.org/2002/09/wbs/33280/aria-2025-charter-review/results

[plehegar]

Thanks @npdoty

#622 should fix this.

@plehegar I think this passes for minor changes under Managing changes to charters after review and we could include it.

agreed.

[svgeesus]

. I assume at some point https://www.w3.org/groups/ig/privacy/ will clearly indicate that work is now happening at https://www.w3.org/groups/wg/privacy/

Good point, and I agree that it should.