Re: Programmatically determined link context

Hello,
I know that VoiceOver on Mac used to indicate terms and definitions, when in “group mode”. I don’t remember when I last saw this, and most folks don’t use group navigation in VOiceOver because it can do some things differently from all other screen readers. 
But in the MDN examples I just viewed, the DT was just showing up as text, as though it had been downgraded. I expect that non-HTML developer types just considered this extra verbosity and advocated its removal.
I last remember experiencing VoiceOver speaking terms in the “Daring Fireball “ web site and/or the RSS in NetNewsWire. I’ll try and see if they show up there.
 

> On Aug 12, 2023, at 8:53 PM, Adam Cooper <cooperad@bigpond.com> wrote:
> 
> Zip. Nada. None. nil. Zero. There is no screen reader I am aware of that has ever presented the relationship between description and term(s), yet they are still recommended in the belief that they are ‘accessible’ for screen reader users. 
>  
> Adding ARIA shouldn’t be necessary to make this work - ‘programmatically determinable’ is too imprecise to be of any utility given that all it really means is that a DOM node has access to a certain ancestor and a desired relationship is established.
>  
> These desired relationships between this or that DOM node are not specified anywhere normatively … (eg: UAAG, text alternative computation, etc.)
>  
> The phrase ‘provided in a way’ in the definition of programmatic determination is a purposely ambiguous catch-all.
>  
> It’s plausible that, given this lack of specification and the wholesale misuse of markup like description lists, screen reader manufacturers are reluctant to implement features that ‘extract and present’ the so-called semantics of these implementations.
>  
> Given the ambiguity of programmatic determinability, it’s hard to see how anyone can pass or fail 2.4.4 without using the sticky plasters that are sufficient or advisory techniques. 
>  
>  
>  
>  
>  
>  
> From: Marc Haunschild <marc.haunschild@accessibility.consulting <mailto:marc.haunschild@accessibility.consulting>> 
> Sent: Saturday, August 12, 2023 4:58 PM
> To: Adam Cooper <cooperad@bigpond.com <mailto:cooperad@bigpond.com>>
> Cc: Juliette McShane Alexandria <mcshanejuliette@gmail.com <mailto:mcshanejuliette@gmail.com>>; Kevin Prince <kevin.prince@fostermoore.com <mailto:kevin.prince@fostermoore.com>>; Steve Green <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk>>; Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com>>; w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
> Subject: Re: Programmatically determined link context
>  
>  
> 
> 
>> And how does one consume this programmatic context using a screen reader?
>  
> I’m not an authentic screenreader user, so I don’t know which screenreader supports this programmatically determinable relationship and how to use it.
>  
> Also I don’t say. That this is a best practice.
>  
> You of course can support users with aria (aria-described by on the links should do the job). But when there is an AAA SC, it already indicates that there might be a better way to provide information about a link target.
>  
> In my opinion it’s best to use the content of the a-Element to provide a meaningful accessible name for every link.
>  
> As a tester I even might be seduced to give a fail for a dd that holds a meaningless Link only. Because it is for description and one can think, that’s not the proper role for what this element is used for, as there is no description.
>  
> This might be a little harsh, as a dl has no implicit semantics, but the ARIA Spec also says:
>  
> "The elements marked with No corresponding role, in the second column of the table do not have any implicit ARIA semantics <https://www.w3.org/TR/wai-aria-1.2/#implicit_semantics>, but they do have meaning and this meaning may be represented in roles, states and properties not provided by ARIA, and exposed to users of assistive technology via accessibility APIs.“
> https://www.w3.org/TR/html-aria/#dfn-no-corresponding-role <https://www.w3.org/TR/html-aria/#dfn-no-corresponding-role>
>  
> This once again supports, that it’s the responsibility of the screenreader vendor to analyse the given relations between elements and help the user to access it.
>  
> Anyway: while a dl might work for passing SC 2.4.4 it still can fail other SCs like SC 4.1.2:
> Name, Role, Value (Level A).
>  
> Marc
>  
> 
> 
>>  
>> From: Marc Haunschild (Accessibility Consulting) <marc.haunschild@accessibility.consulting <mailto:marc.haunschild@accessibility.consulting>> 
>> Sent: Thursday, August 10, 2023 3:13 PM
>> To: Juliette McShane Alexandria <mcshanejuliette@gmail.com <mailto:mcshanejuliette@gmail.com>>
>> Cc: Kevin Prince <kevin.prince@fostermoore.com <mailto:kevin.prince@fostermoore.com>>; Steve Green <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk>>; Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com>>; w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
>> Subject: Re: Programmatically determined link context
>>  
>>  
>>> The Understanding document says the "same list item". I believe the term and definition are considered the 'same' item.
>>  
>> Besides there is a sufficient technique (H80) that uses a preceding heading as context.
>>  
>> The relationship between dt and dd is similar to text with a heading.
>> 
>> 
>> 
>>> The HTML spec says:
>>>  
>>> "The dt/dd element represents the description, definition, or value, part of a term-description group in a description list (dl element)." (emphasis added)
>>  
>> Anyway I still think that description lists are not well designed in html  - as a developer I wished about a billion times there would have been a grouping element around dt and dd - but that’s another story…
>> 
>> 
>> 
>>> I would agree that for the purposes of WCAG 2.1 level AA SC 2.4.4 if the needed context is in a dt/dd pair then the link has appropriate context
>>  
>> Full ACK - although dt can be followed by multiple dds - so it’s not necessarily a pair.
>>  
>> Sorry for being a little pedantic. I’m German. I just try to fit into the stereotype 
>> 😉
>> Marc
>> 
>> 
>> 
>>> Best,
>>> Juliette
>>>> On 8/9/2023 11:34:34 AM, Kevin Prince <kevin.prince@fostermoore.com <mailto:kevin.prince@fostermoore.com>> wrote:
>>>> 
>>>> I’d agree – the list gives them a clear relationship.
>>>>  
>>>> Kevin
>>>>  
>>>> Kevin Prince 
>>>> Product Accessibility & Usability Consultant
>>>>  
>>>> Foster Moore
>>>> A Teranet Company
>>>>  
>>>> E kevin.prince@fostermoore.com <mailto:kevin.prince@fostermoore.com>
>>>> Christchurch
>>>> fostermoore.com <http://www.fostermoore.com/>
>>>> From: Steve Green <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk>>
>>>> Date: Thursday, 10 August 2023 at 2:40 AM
>>>> To: Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com>>, w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>>
>>>> Subject: RE: Programmatically determined link context
>>>> 
>>>> CAUTION: This email originated from outside of the organization. 
>>>>  
>>>> I would say that they are.
>>>>  
>>>> Steve Green
>>>> Managing Director
>>>> Test Partners Ltd
>>>>  
>>>>  
>>>> From: Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com>> 
>>>> Sent: Wednesday, August 9, 2023 2:20 PM
>>>> To: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
>>>> Subject: Programmatically determined link context
>>>>  
>>>> Hello
>>>>  
>>>> Just a quick one. Are the terms in a description list <dt> part of the programmatically determined link context for links in the corresponding definition tag <dd>
>>>>  
>>>> Example:
>>>> <dl>
>>>> <dt>first page</dt><dd><a href>link</a></dd>
>>>> <dt>second page</dt><dd><a href>link</a></dd>
>>>> 
>>>> </dl>
>>>> 
>>>> We believe they are but weren't sure how stringent the definition of 'programmatically determined link context' was as it says 'includes...' so we weren't sure if that was 'includes only' or 'includes but is not limited to'. 
>>>> 
>>>> Thanks! 
>>>> 
>>>> Sarah
>>>> 
>>>> Sent from Outlook for iOS <https://aka.ms/o0ukef>