RE: Nested links (not related to children presentational issue in ARIA 1.1)

I second the need for discussion but I am far less sure of the solution.

 

It is not clear to me that the primary issue with making such “drill into” or layered design patterns fully accessible is a role/API gap. At this point, I think making them friendly for non-screen reader users is harder than making them screen reader accessible. With the exception of the common dialog box, I am not aware of any accepted or common visual affordances that communicate their associated keyboard interaction models. Before we add new roles, it would be useful to have some well researched keyboard design patterns that work for sighted keyboard users as a starting point.

 

I do not see nested links as a primary driver here. While they may be appearing in the wild, it is hardly clear that they are a good idea from a semantic perspective. Nested links seem more like a way of coding click behavior for regions of a page that is easier than listening for clicks on nested divs. Such constructs have existed for years. Functionally, they are similar to an image map where the map is semantic content instead of an image.

 

When programmers use links instead of divs to get this functionality, They are using a semantic element for its functional behavior but ignoring its semantic meaning. The best way to make it accessible may not be to try to impute semantic meaning but rather allow role none and tabindex -1 on the links and supplement the design with elements that create clear interaction models that equally support both sighted keyboard and screen reader users. This is very easy; we have been doing so for a long time. 

 

If HTML ever permits nested links, one possible solution to the semantic and keyboard problems would be to require that aria-labelledby be used to refer to a portion of the link content, that is not nested, that would serve as the actual link for keyboard only and screen reader users. Screen readers would read that single piece of text as the link and that text would be focused when keyboard users tab to the link. Then developers get their “easy way to make a clickable region” and non-mouse users get a normal link.

 

Matt

 

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] 
Sent: Monday, June 27, 2016 1:11 AM
To: James Nurthen <james.nurthen@oracle.com>; public-aria@w3.org
Subject: RE: Nested links (not related to children presentational issue in ARIA 1.1)

 

>> I have long thought that what we need is the ability for ANY object which can take focus to expose the fact that it has descendants, much like grid cells do today in some UIs.

 

I second that and not just for descendants. Having elements with role=listitem focused is not uncommon. Doing so, Jaws/IE does not support speaking aria-posinset/setsize on focus although valid properties in ARIA 1.0 for listitem role. I see things like this for years now and we need a more detailed discussion here.

 

Regards

Stefan

 

 

 

From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: Freitag, 24. Juni 2016 23:06
To: public-aria@w3.org <mailto:public-aria@w3.org> 
Subject: Re: Nested links (not related to children presentational issue in ARIA 1.1)

 

I have long thought that what we need is the ability for ANY object which can take focus to expose the fact that it has descendants, much like grid cells do today in some UIs. A user could then use a keystroke (or gesture) to switch between interacting with the root object, or its children. This would allow a common UI model to be implemented across all sorts of different components and would resolve many of the tensions we have seen recently where UX patterns are created which aren't supported by the common Accessibility models.

 

On 6/24/2016 1:44 PM, Amelia Bellamy-Royds wrote:

In response to the feedback & testing results, I'm going to ask the rest of the SVG team to revert the previous decision & to add in explicit language neutering nested <a> elements (so that content still displays but the href is ignored; the nested content would not be its own link). 

 

SVG issue for that: https://github.com/w3c/svgwg/issues/178

 

Given that it is still possible to create a nested link structure in HTML via JavaScript, I think some follow-up needs to happen on the HTML side to create similar behavior.  Does anyone want to spearhead that, or should I file issues myself?

 

 

Longer term discussion for ARIA:

 

De-facto nested links are actually quite common these days, at least from the perspective of mouse/tap users.  E.g., on the Twitter web site, an entire tweet-block acts like a link to the tweet's permalink page, but spans of text within it are still links to other content.  The outer "link" is constructed through JS click event handlers, rather than actual nested <a> elements.  Nonetheless, the logical structure, and the way it is perceived by end users is that there is one large linked object which contains specific links nested inside it.  However, screen reader users aren't receiving this structure because it cannot be exposed effectively in the ARIA / Accessibility API models.

 

This is therefore another piece of evidence that ARIA 2 will need a deep discussion on how to support nested interactive content.  The "one element, one role" model, based on the limited number of widgets in desktop APIs of the 1990s, just isn't enough for modern web of rich custom widgets, including composite nested and multi-functional widgets, and including interactive components that also represent document structure such as headings and list items.

 

~Amelia

 

On 24 June 2016 at 22:07, Birkir Gunnarsson <birkir.gunnarsson@deque.com <mailto:birkir.gunnarsson@deque.com> > wrote:

This does not work as an html construct (it is invalid after all).
There would have to be extremely urgent and very convincing reasons
why it should be allowed in SVG.


On 6/24/16, White, Jason J <jjwhite@ets.org <mailto:jjwhite@ets.org> > wrote:
>
>> On Jun 24, 2016, at 03:14, Schnabel, Stefan <stefan.schnabel@sap.com <mailto:stefan.schnabel@sap.com> >
>> wrote:
>>
>> Testing of http://mcc.id.au/temp/nested-links.html
>>  The entire construct is treated as a single link in VoiceOver/Safari
>> under OS X, both when navigating with the tab key and when using VoiceOver
>> commands for navigation.
>

 

 

-- 
Regards, James 

 <http://www.oracle.com> 
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781>  | Mobile: +1 415 987 1918 <tel:+1%20415%20987%201918>  | Video: james.nurthen@oracle.com <mailto:james.nurthen@oracle.com>  
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065 
 <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment