search

w3c / html-aria

ARIA in HTML
https://w3c.github.io/html-aria/
Other
181 stars 48 forks source link

link element inconsistent between html-aria and html-aam #205

Closed carmacleod closed 3 years ago

carmacleod commented 4 years ago

HTML-ARIA for link element says:

link element with a href | role=link | No role or aria-* attributes

HTML-AAM for link element says:

No corresponding role | Not mapped | ...

Not sure what the correct mappings should be in either spec; just pointing out an inconsistency.

JAWS-test commented 4 years ago

HTML spec says

Two categories of links can be created using the link element: Links to external resources and hyperlinks. The link types section defines whether a particular link type is an external resource or a hyperlink. ... If the rel attribute is absent, has no keywords, or if none of the keywords used are allowed according to the definitions in this specification, then the element does not create any links.

So the role does not depend on the href, but on the value in rel.

But: Since the link element is not rendered by the browser and does not exist in the accessibility tree, there should be no mapping.

The links are applied to the entire page and can be displayed as navigation targets by the browser (probably via the menu). But we don't need any mapping, because the links are never displayed within the HTML page.

scottaohara commented 4 years ago

The link element may be used in the body of a document if it has a body-ok rel. With CSS, one can get the link to be visually displayed, and by adding a tabindex=0, it can be keyboard focusable - https://codepen.io/scottohara/pen/bGNgoGL (note: the markup of this codepen passes the HTML validator)

The demo in the codepen likely will not be announced as having any content with IE11, as I'm using CSS pseudo content to inject the text "what a bad idea", and if memory serves, CSS content is not properly exposed by IE11.

Quickly testing the linked codepen with Apple's a11y inspector, the link has a platform exposed role of AXLink, if it has an href attribute. If the href is removed, it is exposed as an AXGroup.

Adding or removing the rel has no impact on whether it's exposed as a AXLink or not, but without a valid rel with body-ok value, it does become invalid as far as what's allowed by the HTML specification.

So, with all that said, if we were to update anything with ARIA in HTML, it would be to say link has no corresponding role if it does not have an href. If someone wants to make a PR to add in that information, I'd accept it...but I think it's pretty low priority, as with or without href, a link should still not be allowed to have any ARIA attributes applied to it.

What I think this issue has helped uncover is that HTML AAM does need to be updated to record platform mappings for the link element (likely just resulting in link's mappings pointing to role=link). However, we'd also likely want to have a comment there explaining that typically link is not a user-facing element.

JAWS-test commented 4 years ago

The trick of making an invisible element visible also works with other invisible elements such as style, script, and template. But it doesn't change the fact that a link element is usually invisible and doesn't exist in the accessibility tree.

scottaohara commented 4 years ago

i'm not disputing that fact...

What i am stating is link does has a platform mapping if exposed, and that mapping is tied to if the href is present on the element, and not the rel.

Again, per the purposes of this specification, it's largely irrelevant because it doesn't change the fact that, even if exposed developers should not use ARIA on link elements.

However, for the purposes of HTML AAM, the mappings are presently inaccurate as the element does have a mapping, even though its default state is for it to not be exposed to the accessibility api.

JAWS-test commented 4 years ago

The question is whether we follow the HTML specification or what browsers are currently doing:

I would suggest that at https://w3c.github.io/html-aria/#el-link instead of "role=link" the following is entered: "No corresponding role".

scottaohara commented 4 years ago

(unintentionally) many hours later...

MSAA/AXAPI both map the element to a link (though MSAA may well just be noting the element's name)

IA2 & UIA does not expose a link mapping at the platform level. but as you noted, Firefox does allow it to be activated like a link.

Safari will both announce and treat an exposed link as a link.

So it's chromium based browsers that will not treat an exposed link as anything but a text node.

Firefox will allow an exposed link to be activated as if it were an a href, but may not expose it with a link role.

Safari will treat an exposed link as if it was an <a href="...">.

so we are a bit split here, and honestly I can go either way at this point.

I tend to think it's better to provide a mapping for an element which may (even though the chance of this happening is largely confined to this issue thread) have the opportunity to be exposed to users, even if that mapping is not regularly exposed to the accessibility api. However, this doesn't match the behavior of an exposed link in Chromium browsers.

The counter argument is to not map it at all, (no corresponding role) and rather file bugs against browsers (safari, firefox) to negate functionality for something that should thus not act as a link... but again, also should rarely ever be exposed to users...so...

@carmacleod, @stevefaulkner do you have an opinion on which way this should go? Again... this is a rather twisted issue as it may impact ARIA in HTML, HTML AAM, both or neither :)

carmacleod commented 4 years ago

No opinion. I've only ever used link for "pulling things in" - never for anything UI. (Wouldn't want to, because who knows what would happen. ;)

Happy to go with whatever @stevefaulkner decides. :)