Add aria-link-target property

[yatil]

Description of bug or feature request

To allow assistive technology to announce the target of a link, an aria-link-target (or similar) property should be introduced. This attribute could have a value from list of possible link targets. There is precedent for that in the HTML target attribute (which should be matched, see this html-aam issue).

The mapping should reference the existing valid browsing context name or keywords in HTML, however one would generally expect that the default context is set.

This feature should initially be used to provide information if a link uses a new window, a new tab or stays in the same context.

a@target="_blank" could be matched to the aria-link-target property value of new. The browser should then amend this for assistive technologies to announce the setting that the user prefers for opening new contexts: “new tab” or “new window”.

Will this require a change to CORE-AAM?

If unknown, leave blank. If relevant, link bug.

Will this require a change to the ARIA authoring guide?

If unknown, leave blank. If relevant, link bug.

PR tracking (for feature tracking, leave as is when submitting)

• ARIA PR:
  • Editor's Draft commit:
  • Working Draft commit:
• Core AAM PR:
• AccName PR:
• APG PR:

Implementation tracking (for feature tracking, leave as is when submitting)

• WPT test:
• Implementations (link to issue or when done, link to commit):
  • WebKit: ISSUE
  • Gecko: ISSUE
  • Blink: ISSUE

[scottaohara]

thanks for the issue @yatil - interestingly I actually started writing a proposal for an aria-target attribute a few months back, but never got around to finishing it. But maybe this is a good time to at least post what I had. It's a little different, as the proposal was to combine the need for a "opens in a new window" with a potential replacement for aria-haspopup. Here's the rough text of what I had written:

edit: changed attribute name per comment

aria-opens

Indicates that triggering the interactive control will result in either the appearance of, and change in focus to, an in-page popup or a new user agent window.

The aria-target property is a token type. User agents MUST treat any value of aria-target that is not included in the list of allowed values, including the empty string or undefined, as if the value false had been specified. Assistive technologies MUST NOT expose the aria-target property if it has a value of false.

NOTE:
This attribute is to be used for some instances where aria-haspopup was expected in previous versions of ARIA. (more information to come about those potential changes)
ENDNOTE

• A popup token indicates the element will invoke a type of non-menu popup and that a user's focus will be sent to it.
• A window token indicates that triggering the element will result in a new user agent window appearing to render the fetched resource.

---

to your issue's point of using the other values of target... I imagine those could be worked into this as well.... though I wonder if people will know/care about what things like self or parent mean?

[yatil]

Thanks for sharing!

to your issue's point of using the other values of target... I imagine those could be worked into this as well.... though I wonder if people will know/care about what things like self or parent mean?

Yeah, I was unsure about that. Most of them would probably not be actively announced, but I also did not want to limit it to the “new window”/“new tab” use case.

[alextait1]

Upvote!

[racheleditullio]

Yes please

[janmaarten-a11y]

Yes please and thank you!

[SteveALee]

+1. Fills a gap

[anders-kaffia]

Yes please!

[stevefaulkner]

+1

[JonathanFBell]

+1

[aleventhal]

We are going to have to get ATs to update once we start exposing the information.

Some authors already have a little icon for "opens in new tab" along with alt text. I know James Teh was complaining about the verbosity of that. It would be good if ATs used maybe an earcon (sound) when this semantic is present, in order to help avoid long announcements, and duplicate-sounding announcements.

Unfortunately, if the author is already adding this icon with alt text, and we expose the new semantic for target="_blank" as the html-aam issue suggests, there will be a double indication in newer ATs that support the semantic.

Anyone have any thoughts on how to make things overall better and less annoying?

[cookiecrook]

FWIW, I'm all for exposing target to APIs.

Once that change is made, I'm not convinced there will be a lot of need for an ARIA-only attribute that does the same thing. It would only be useful/necessary in the cases where the browser engine couldn't already detect the target. For example:

• a non-link that uses role=link (e.g. <div role=link>)
• a JavaScript-intercepted click where the author doesn't want to use target for some reason? E.g. They don't want the popup to pop up if JS is off? Even then, they could insert the attr with JS. (Reaching here, as I'm not sure why this would need to be a thing.)

Both of those are already against the authoring advice to avoid ARIA when possible so, once API support for target exists, this new ARIA attr would be supporting an uncommon anti-pattern.

Beyond that, I don't think a new attribute should be name-locked to either link or target... If this is about the resulting behavior (opens in new window), new API should be related to that concept... Maybe tie this in with the other discussions about reworking aria-haspopup?

[aleventhal]

Beyond that, I don't think a new attribute should be name-locked to either link or target... If this is about the resulting behavior (opens in new window), new API should be related to that concept... Maybe tie this in with the other discussions about reworking aria-haspopup?

Neat. Maybe, aria-opens= popup|window|...

[scottaohara]

in my draft proposal for the potential attribute "target" was not meant to be a 1:1 with target. Aaron's idea of "opens" is a better choice. i've updated that bit of my previous comment to reflect this.

[yatil]

I think there is a potential to go beyond the target attribute. For example for the download attribute. Maybe aria-destination would be better.

That said, I'm not super hung up on the actual naming on the feature, so all input is welcome.

[brennanyoung]

A big +1 for including the download attribute in the implementation here, since this can be very disorientating without visual cues, and those visual cues aren't always obvious.