[wg/aria] [Accessible Rich Internet Applications] Group Charter

[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