Clarity for programmatically determined link context term example

[scottaohara]

The current (and by that I mean since wcag 2.0) programmatically determined link context term example text reads:

In HTML, information that is programmatically determinable from a link in English includes text that is in the same paragraph, list, or table cell as the link or in a table header cell that is associated with the table cell that contains the link.

The issue I see with this is the simple mention of 'list', rather than 'list item' - particularly in relation to the other examples provided.

Without that qualification, it reads that the following would be fine:

<ul>
  <li>All my context</li>
  <li>...</li>
  <li><a href=...>learn more</a></li>
</ul>

but based on all the issues/discussion that already exist concerning this topic, and the additional examples related to tables in that example text, the following (text and link within the same list item) is likely what was actually intended):

<ul>
  <li>All my context <a href=...>learn more</a></li>
  <li>...</li>
</ul>

Additionally, I think to help resolve issues like #2109 - since this example text is already mentioning "in html", it might be a good idea to link the word 'paragraph' to the HTML definition of paragraph, so as to help squash the question of "does paragraph mean 'paragraph' or p element?" without having to amend that text further to indicate that <div>.... <a href>...</a></div> or <blockquote>.... <a href=>...</a> ...</blockquote>, etc. are also providing said context.

[patrickhlauke]

also...maybe just me, but what is the meaning of the note there

Since screen readers interpret punctuation, they can also provide the context from the current sentence, when the focus is on a link in that sentence.

Are we talking about weird screen reader heuristics that try to work out what is a sentence?

[patrickhlauke]

also, in the wider topic, i'm still not sure if we're now ok to treat a preceding heading as being "programmatically determinable" context or not. i seem to remember we had arguments for and against, and (still) have aa advisory technique (with the usual confusing caveat that advisory can both mean "it's sufficient, and then goes beyond what the SC demands" and "it doesn't actually satisfy the SC on its own") that uses headings to provide context...but i'm sure there's related issues/PRs around that aspect somewhere

[detlevhfischer]

For what it's worth, the current German BIK BITV-Test consensual stance is that the preceding heading is considered sufficient for supplying a link's context. I believe (remember from some call) that (at least parts of) the WG in retrospect consider it a mistake to have demoted H80 from sufficient to advisory.

[scottaohara]

personally, i also think that a preceding heading 'should' be considered enough - but that doesn't really jive with what the normative text says in relation to the definition of 'programmatically determined link context'.

For the preceding heading to work under the current programmatically determined link context definition/example - the preceding heading would have to also provide the accessible name for a grouping container both the heading and the link exist in. e.g.,

<div role=group aria-labelledby=h>
  <h# id=h>whatever</h#>
  <p>...
  <p>...
  <p><a href=#>learn more</a></p>
</div>

this then matches the example text indicating that a sole link in a table cell needs to be associated with a table header cell to provide the necessary context.

Otherwise, the heading and the link just aren't programmatically associated. One could make the argument that if the example text did not refer to the table header/cell association - then 'programmatically determined' and the definition of 'relationships' are squishy enough definitions that sure, a heading and a link in a following paragraph could be programmatically determined - as could all the information from individual list items and a sole link (circling back to this PR). But the example text for 'programmatically determined link context' squashes all that with very clearly saying that the text context and the link needs to be in the same paragraph, or table cell OR a table header cell is associated with the cell that contains the link. Again hence why the mention of list alone doesn't make sense, because it contradicts the neighboring examples.

If people want to use this as an opportunity to re-introduce the idea that a heading should be enough to provide context without the programmatic association I demoed above - i'm all for that. However, why just a preceding heading? Why couldn't a preceding paragraph provide that context? It's arbitrary to say one can and the other couldn't when both 'could be' programmatically determined from relationships, but neither are actually programmatically associated - as the table header + cell relationship example so clearly outlines.

[patrickhlauke]

additional information that can be programmatically determined from relationships with a link

the way i'd interpret it is more: is there some unambiguous way for it to be programmatically determined (though that then clashes with the usual nebulous "but is it accessibility supported?" conundrum). as mentioned...in some previous discussion on this, "find the nearest preceding heading" is trivial for software to do, and it's unambiguous, so to my mind would count. the fact that SRs (or at least "not all SRs") don't do it/don't offer a way to do it/don't expose it is the clincher.

then again, there's oodles of aria-* stuff that SRs also don't expose, and yet we push for it in 4.1.2 etc.

but yes, on the more specific aspect here of "why does this count as 'programmatically determined', but not that..." I agree, it's a bit arbitrary, and probably coloured in no small part by what SRs used to expose back in ... 2007 or so

[scottaohara]

yup. and i'd agree with you completely if not for the example text I've referenced which is emphasizing the strictness (but per this PR, being contradictory re: lists).

Would be happy if this could be changed in the opposite direction, to be more permissive and thus what you and Detlev are saying would, imo, be fine.

[scottaohara]

see also https://www.w3.org/WAI/WCAG21/Techniques/html/H77 re list vs list item change

[alastc]

Just to get this straight for a survey, are the options:

1. Use the PR, so it is a fairly strict interpretation (which seems to align with H77).
2. Allow for a more flexible approach, allowing for lists and bringing H80 (heading above) to sufficient?

I.e. have things (AT) improved so that programmatic associations work better?

[awkawk]

Relevant history for H80: https://lists.w3.org/Archives/Public/w3c-wai-gl/2014JulSep/0122.html