This is a summary of the discussion we had in the APA call - the main outputs of which are:
Proposed key questions and actions to help us further the discussion.
A proposed more fleshed-out agenda (developed based on the APA call’s agenda) for a TPAC breakout.
The revised, more detailed agenda outline can be found below.
Calendar invite: https://www.w3.org/events/meetings/b3d3fb17-9637-4fae-a68a-39f8f9a6719a/20251015T100000/ This links to:
Explainer: https://github.com/webplatformco/explainers/blob/main/html-element-references/README.md
Alice’s summary of the discussion and concerns: https://github.com/whatwg/html/issues/10143#issuecomment-3195739405
APA call minutes: https://www.w3.org/2025/10/15-apa-minutes.html
Many people contributed to the discussion, and of course to the GitHub thread. The summary below is only a subset, which seemed, based on our discussion, to have most traction for use in a discussion at TPAC.
What exactly are the pain points associated with the status quo? I.e. First, we should ask developers what they struggle with currently.
Sarah’s experience with IDREFs: https://github.com/whatwg/html/issues/10143#issuecomment-3175870635
David (Helix Opportunity) offered to assist with user research.
Could accessibility people provide more details on the expected large costs of changes to the accessibility infrastructure that would be needed as a result of changes to IDREFs?
On the use of frameworks, and proposals to concentrate on templating as the solution to the expected current issues with IDs (duplicates, or maybe sharing IDs):
Paul Grenier raised the point that if we focus too much on duplicate IDs, we risk missing other problems, and more fundamental problems devs face: underneath all this is the lack of awareness of how accessibility problems arise, and how to fix them.
Some accessibility people want to explore the template solution to duplicate IDs, as it lacks the costs of the scoping (or selectors) proposals. Jeffrey pointed out that this excludes people who are not using custom elements (or frameworks that provide their own solution) from benefiting from the solution.
Jeffrey felt that HTML should provide a built-in way for devs to say “I’m going to make multiple copies of this subtree, and each copy should work as intended” without having to rely on people using frameworks.
Sarah asks the question: is the problem generation of IDs - or is it the communication across component boundaries of the IDs you have generated?
Regarding relative references: can we find out how useful or fragile they may be? (Sarah is looking into this across two codebases).
TPAC Breakout to be proposed. The more detailed agenda below could be used as the basis for that discussion.
Sarah is looking into two codebases of component libraries to assess the risks involved in relative references.
Recap of the possible benefits
Improved accessibility by removing duplicate IDs
Improved DX by providing ways other than IDs to refer to related elements
Recap of the accessibility concerns
Authoring-time
Developer understanding of relative references
Does HTML in the wild lend itself to relative references?
Content maintenance
Browser implementation
Assistive Technology implementation
Discussion about what user research would be helpful
Quantifying the problems
What exactly are the pain points associated with the status quo? I.e. First, we should ask developers what they struggle with currently.
Does the fact that tooling provides workarounds mitigate this?
Is most HTML amenable to relative references?
Justifying the development cost through end-user need: will this make pages more accessible?
…and how it might be carried out.
Surveys of the problems with the status quo (i.e. asking developers)
Sarah offered to do some research on possible risks of relative refs in two component libraries’ codebases