Closed Bug 854796 Opened 12 years ago Closed 1 year ago

HTML a and area having no @href shouldn't have link role

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

RESOLVED FIXED
117 Branch
Tracking Status
firefox117 --- fixed

People

(Reporter: surkov, Assigned: nlapre)

References

(Blocks 3 open bugs, Regressed 1 open bug)

Details

(Whiteboard: [AT-debrifing-needed])

Attachments

(1 file)

Jason noticed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=16629 that it would be more correct in MSAA terms to not map html:a and html:area having no @href attribute into link role. CVS history doesn't have records about this and we do that from beginning of times. IE maps html:a and html:area having no @href into ROLE_SYSTEM_TEXT. Is there objections to not follow this?
(In reply to alexander :surkov from comment #0) > CVS history doesn't have records about this and we do that from beginning of > times. I suspect it was for IE compatibility; see below. > IE maps html:a and html:area having no @href into ROLE_SYSTEM_TEXT. Are you sure? This certainly isn't the case for me with IE 9. <a>foo</a> gives me ROLE_SYSTEM_LINK. It even exposes STATE_SYSTEM_LINKED, which is really annoying. I certainly think this is a good idea in theory; we've always had to hack around it in NVDA. Two things to be aware of: 1. Some ATs might depend on <a name="foo">bar</a> having a role of link. This would need to be checked. NVDA doesn't. 2. <a name="foo">blah</a> should still produce an accessible, even if it has a generic role such as section or text frame, so that it can be the target of a scrolling start event.
(In reply to James Teh [:Jamie] from comment #2) > (In reply to alexander :surkov from comment #0) > > CVS history doesn't have records about this and we do that from beginning of > > times. > I suspect it was for IE compatibility; see below. > > > IE maps html:a and html:area having no @href into ROLE_SYSTEM_TEXT. > Are you sure? This certainly isn't the case for me with IE 9. <a>foo</a> > gives me ROLE_SYSTEM_LINK. It even exposes STATE_SYSTEM_LINKED, which is > really annoying. Oh, I didn't check. I supposed they suggested that wording in the spec. > I certainly think this is a good idea in theory; we've always had to hack > around it in NVDA. Two things to be aware of: > 1. Some ATs might depend on <a name="foo">bar</a> having a role of link. > This would need to be checked. NVDA doesn't. > 2. <a name="foo">blah</a> should still produce an accessible, even if it has > a generic role such as section or text frame, so that it can be the target > of a scrolling start event. sure
So we shouldn't use HTMLLinkAccessible for html:a having no @href (see HTMLLinkAccessible::IsLinked(), use HyperTextAccessible instead. Don't use HTMLAreaAccessible for area (see HTMLImageMapAccessible), use LeafAccessible class instead.
Jamie, is it normal/correct that ROLE_SYSTEM_TEXT have nested ROLE_SYSTEM_TEXT?
Blocks: treea11y
(In reply to alexander :surkov from comment #5) > Jamie, is it normal/correct that ROLE_SYSTEM_TEXT have nested > ROLE_SYSTEM_TEXT? I'd say this is abnormal. I think it'd be better to use text frame for the parent role.
Apologies. Jamie, of course, is totally correct. IE uses ROLE_SYSTEM_LINK and STATE_SYSTEM_LINKED for both <a> and <area>, whether or not there's an @href. Regardless of IE's behaviour, are you suggesting a better mapping for <a> and <area> without @href would be IA2_ROLE_TEXT_FRAME? Or is it better for AT if the implementation is the same across browsers and so stick with ROLE_SYSTEM_LINK but not expose STATE_SYSTEM_LINK?
(In reply to Jason Kiss from comment #7) > Regardless of IE's behaviour, are you suggesting a better mapping for <a> > and <area> without @href would be IA2_ROLE_TEXT_FRAME? It is a more correct mapping, certainly. > Or is it better for > AT if the implementation is the same across browsers and so stick with > ROLE_SYSTEM_LINK but not expose STATE_SYSTEM_LINK? Better is a very subjective term here. It could break backwards compatibility, so it'll require a lot of testing. I'm happy for it to be made - NVDA will be just fine with it - but other AT vendors may disagree. In other words, with the nicest possible intent, I don't really care either way. :)
Whiteboard: [AT-debrifing-needed]
Update, Jason suggested to use IA2_ROLE_SHAPE for areas having no @href
(In reply to alexander :surkov from comment #9) > Update, Jason suggested to use IA2_ROLE_SHAPE for areas having no @href It was really James who provided the suggestion :) https://twitter.com/jcsteh/status/362340665222377473
(In reply to Jason Kiss from comment #10) > (In reply to alexander :surkov from comment #9) > > Update, Jason suggested to use IA2_ROLE_SHAPE for areas having no @href > > It was really James who provided the suggestion :) > > https://twitter.com/jcsteh/status/362340665222377473 Sorry, I misread it, I think I was reading the first 'J' letter only :)
Severity: normal → S3

Time has marched on. The HTML-AAM spec is clear that <a> without an href shouldn't be exposed with the link role. Chrome has implemented it this way for quite some time (perhaps since the beginning), so we can assume JAWS and other ATs don't have a problem with this. As noted above, NVDA is fine with it. We're currently failing testing/web-platform/tests/html-aam/roles.html [el-a-no-href] because of this.

Blocks: a11y-wpt

Per the HTML-AAM spec, a and area elements without href attributes should have
generic roles. This revision implements this preference in the link accessible's
NativeRole function by checking for the attribute there. This revision also changes
the relevant WPT test expectations.

Assignee: nobody → nlapre
Status: NEW → ASSIGNED
Pushed by nlapre@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7b4ce93feaf8 Anchor, area elements without href shouldn't have link role, r=Jamie,devtools-reviewers
Regressions: 1845194
Regressed by: 1845221
No longer regressed by: 1845221
Regressions: 1845221
Keywords: access, regression
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 117 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: