Summary of Wednesday's IDREFs discussion

Hello all,

Thanks to everyone involved in Wednesday's call (and the wider thread). I
have been through the minutes, and have included below (and attached as
Markdown and HTML files) a summary, containing some key points and
questions, and a proposed outline for a future TPAC discussion (breakout) -
to be proposed. I will also send this to the separate thread we have with
our guests on the call.

If you have feedback on the summary, or further comments for discussion,
please reply. Also if you'd like to be involved in the TPAC breakout, or
carrying out any of the further research, please let us know; thanks!

Best regards,


Matthew

# Notes from APA discussion on proposed IDREF enhancements

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/202
51015T100000/> This links to:

  * Explainer:
<https://github.com/webplatformco/explainers/blob/main/html-element-referenc
es/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.

## Key questions

* 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).

## Actions

* 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.

## More detailed outline (offered for future discussion)

* 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

    + Stability of references / possibility for footgunes

  - Browser implementation

    + Burden of implementation - reverse refs

  - Assistive Technology implementation 

    + Burden of performance - changes to document

* 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

-- 
Matthew Atkinson
Head of Web Standards
Samsung R&D Institute UK
Samsung Electronics
+44 7733 238 020

Samsung R&D Institute (SRUK), Communications House, South Street,
Staines-upon-Thames, Surrey, TW18 4QE. A division of Samsung Electronics
(UK) Limited, a limited company registered in England and Wales with
registered number 03086621 and whose registered address is Samsung House,
2000 Hillswood Drive, Chertsey, Surrey, KT16 0RS, UK. This email (including
any attachments) is private and confidential, and may be privileged. It is
for the exclusive use of the intended recipient(s). If you have received
this email in error, please inform the sender immediately and then delete
this email. Unless you have been given specific permission to do so, please
do not distribute or copy this email or its contents. Unless the text of
this email specifically states that it is a contractual offer or acceptance,
the sender does not intend to create a legal relationship and this email
shall not constitute an offer or acceptance which could give rise to a
contract. Any views expressed in this communication are those of the
individual sender, except where the sender specifically states them to be
the views of Samsung.