439077 - Anchor tags with no attributes should not expose linked accessible state

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre

Gecko incorrectly exposes the linked state to accessibility APIs for anchor ("a") tags which have no attributes. Such anchors are most definitely not linked. Note that despite the linked state, these links (correctly) do not have the focusable state and cannot be focused.

Reproducible: Always

Steps to Reproduce:
1. Open the attached test case.
2. Examine the states of each link object.
Actual Results:  
Both "link object with href" and "link object with no attributes" expose the linked state.

Expected Results:  
"link object with no attributes" should not expose the linked state.

Interestingly enough, even "link object with class" does not expose the linked state. I originally suspected that the lack of href, name, id and onClick attributes would cause the incorrect exposure of the linked state, but it seems the error only occurs when there are *no* attributes.

Comment 1

[James Teh [:Jamie]]

Attachment: Test case.

This sample presents anchor tags with different attributes. Observe the exposure of the linked state for each as noted in the actual and expected results.

Comment 2

[Marco Zehe (:MarcoZ)]

We need to be careful about elements with role="link" attributes. Even though the action when following such a link will most likely be an onclick handler, its role of "link" should in any case make sure we expose the LINKED state for it.

Comment 3

[alexander :surkov (:asurkov)]

Attachment: patch

hg patch contains extra lines for every unchanged file, I don't know how I can get rid them

Comment 4

[alexander :surkov (:asurkov)]

Attachment: patch2

without those lines in the patch

Comment 5

[Marco Zehe (:MarcoZ)]

Comment on attachment 325501 [details] [diff] [review]
patch2

nit:
>+    // This is a either named anchor (not a link with also a name attribute) or

must read:

+    // This is either a named anchor (a link with also a name attribute) or

With that fixed, r=me.

Comment 6

[alexander :surkov (:asurkov)]

checked in on mozilla-central

Comment 7

[James Teh [:Jamie]]

This fixes the bug in question very nicely. However, the linked state is now exposed when a link has an onClick but no href. Imo, it should only be exposed for links with an href. Assistive technologies should use the default action to check for "clickable" elements; i.e. elements with an onClick handler. I'm happy to open a separate bug for this if required, but I wasn't sure about the feasibility of fixing this.

Comment 8

[Marco Zehe (:MarcoZ)]

(In reply to comment #7)
> This fixes the bug in question very nicely. However, the linked state is now
> exposed when a link has an onClick but no href.

What about ARIA links? They'll have a role of "link", they, by nature, won't have an href since an ARIA element is probably not an html:a, but I believe we should definitely keep the "linked" state for these since the role says it's a link.

Please open a separate bug on this one.

Comment 9

[Marco Zehe (:MarcoZ)]

Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062603 Minefield/3.1a1pre