Expose image URL via accessibility APIs

RESOLVED FIXED

Status

()

Core
Disability Access APIs
--
enhancement
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Jamie, Assigned: surkov)

Tracking

({dev-doc-complete})

Trunk
x86
Windows XP
dev-doc-complete
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

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

When no alt or title attribute is provided for an image link, which is unfortunately all too common, screen readers must attempt to provide a "guess" about the purpose of the link. This can be derived from either the URL of the page or the URL of the image. In most cases, the URL of the page, which is exposed by Gecko via accessibility APIs as the value of the link/graphic, is useful. Unfortunately, sometimes it is not and one must resort to the image URL; e.g. http://www.zazz.com.au/, where many of the links seemingly point back to the page itself (they have an onClick overriding them). Gecko does not currently expose the URLs of images via accessibility APIs, so this latter technique is impossible.

I am uncertain as to how the image URL should be exposed. The value is already being used for the link URL, which is important. Perhaps an object attribute or some such?

Reproducible: Always
(Reporter)

Updated

10 years ago
Version: unspecified → Trunk

Comment 1

10 years ago
You can QI to IAccessibleHyperLink and use anchorTarget() to get the URI.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME

Comment 2

10 years ago
Nope, there is currently no way to get to an image's SRC. JAWS probably does it via some iSimple* interface, but through IA2, or even though the platform-independent APIs, there is no way to get to the SRC right now.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 3

10 years ago
Alexander, want to take a stab at it? I believe we should expose the SRC content as an attribute on the imageAccessible (which is the child of the link in Jamie's example page).
Assignee: aaronleventhal → surkov.alexander

Comment 4

10 years ago
Why doesn't IAccessibleHyperlink::anchorTarget() work?
(Assignee)

Comment 5

10 years ago
(In reply to comment #4)
> Why doesn't IAccessibleHyperlink::anchorTarget() work?
> 

because the method returns target of the link but James and Marco wants to get image src.

(In reply to comment #3)
> Alexander, want to take a stab at it? I believe we should expose the SRC
> content as an attribute on the imageAccessible (which is the child of the link
> in Jamie's example page).
> 

Ok, it's easy I think
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 6

10 years ago
Created attachment 316570 [details] [diff] [review]
patch
Attachment #316570 - Flags: review?(marco.zehe)

Comment 7

10 years ago
Comment on attachment 316570 [details] [diff] [review]
patch

>+  nsCOMPtr<nsIContent> content(do_QueryInterface(mDOMNode));
>+
>+  nsAutoString src;
>+  content->GetAttr(kNameSpaceID_None, nsAccessibilityAtoms::src, src);

No check if content was retrieved successfully? Just being paranoid...

Otherwise r=me
Attachment #316570 - Flags: review?(marco.zehe) → review+
(Assignee)

Comment 8

10 years ago
(In reply to comment #7)
 
> No check if content was retrieved successfully? Just being paranoid...
> 
> Otherwise r=me
> 

I don't think it makes sense. It should mean either document or attribute, but they are both impossible with our architecture.
(Assignee)

Updated

10 years ago
Attachment #316570 - Flags: approval1.9?

Comment 9

10 years ago
Looks good. Don't forget docs update if it gets checked in.
This smells of a new feature to me.  Tests?  Explanation of risk?  Re-request approval once explained.
Comment on attachment 316570 [details] [diff] [review]
patch

re-request approval once above question is addressed.
Attachment #316570 - Flags: approval1.9? → approval1.9-

Comment 12

10 years ago
(In reply to comment #10)
> This smells of a new feature to me.  Tests?  Explanation of risk?  Re-request
> approval once explained.

Yes, this is a new feature which we would like to introduce to save IAccessible2 clients from having to use the older iSimple* interfaces we provide for legacy screen reader usage. Exposing the "src" attribute for an image is the last fallback if "title" or "alt" fail. If we were not to provide the SRC attribute, NVDA would have to use iSimple* interfaces for this single instance alone, and we want to avoid them having to do that if possible.

Mochitest upcoming.

Comment 13

10 years ago
Created attachment 316970 [details] [diff] [review]
Mochitest

"moz.png" is a Mozilla Foundation logo I will add if or when this gets checked in.
Attachment #316970 - Flags: review?(surkov.alexander)

Comment 14

10 years ago
Oops, I just noticed that I forgot to change the bug number at the top of the "body". Copy & Paste error, will fix upon checkin.
(Assignee)

Comment 15

10 years ago
Marco, since your test looks a bit more generic than bug requires then would you mind to give a name "test_image.html" or something similar and put there more tests in the future?
(Assignee)

Comment 16

10 years ago
Comment on attachment 316570 [details] [diff] [review]
patch

re-requesting approval, comment #12 gives explanation why it's important to land. Mochitest is attached. We will put it together with the patch if we'll get an approval.
Attachment #316570 - Flags: approval1.9- → approval1.9?

Comment 17

10 years ago
Created attachment 316989 [details] [diff] [review]
Morphed into tests for nsIAccessibleImage interface in addition to already performed tests.

Added testing of nsIAccessibleImage interface methods. Mochitest from bug 429656 can be added to this test as a patch.
Attachment #316970 - Attachment is obsolete: true
Attachment #316989 - Flags: review?(surkov.alexander)
Attachment #316970 - Flags: review?(surkov.alexander)
Comment on attachment 316570 [details] [diff] [review]
patch

a1.9+=damons
Attachment #316570 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 19

10 years ago
Comment on attachment 316989 [details] [diff] [review]
Morphed into tests for nsIAccessibleImage interface in addition to already performed tests.


>+      var cordTypeString = ["screen", "window", "parent"];
>+      for (var i=nsIAccessibleCoordinateType.COORDTYPE_SCREEN_RELATIVE;
>+          i <= nsIAccessibleCoordinateType.COORDTYPE_PARENT_RELATIVE; i++) {

one think: I don't like to assume the order of constants because constants can be regrouped eventually. It's better to put the code below into separate function and pass there a constant as an argument. Otherwise it's ok with me.
Attachment #316989 - Flags: review?(surkov.alexander) → review+
(Assignee)

Comment 20

10 years ago
Checking in accessible/src/html/nsHTMLImageAccessible.cpp;
/cvsroot/mozilla/accessible/src/html/nsHTMLImageAccessible.cpp,v  <--  nsHTMLImageAccessible.cpp
new revision: 1.51; previous revision: 1.50
done
Checking in accessible/src/html/nsHTMLImageAccessible.h;
/cvsroot/mozilla/accessible/src/html/nsHTMLImageAccessible.h,v  <--  nsHTMLImageAccessible.h
new revision: 1.28; previous revision: 1.27
done


leaving open until testcase isn't checked in

Comment 22

10 years ago
Checking in accessible/tests/mochitest/Makefile.in;
/cvsroot/mozilla/accessible/tests/mochitest/Makefile.in,v  <--  Makefile.in
new revision: 1.16; previous revision: 1.15
done
RCS file: /cvsroot/mozilla/accessible/tests/mochitest/test_nsIAccessibleImage.html,v
done
Checking in accessible/tests/mochitest/test_nsIAccessibleImage.html;
/cvsroot/mozilla/accessible/tests/mochitest/test_nsIAccessibleImage.html,v  <--  test_nsIAccessibleImage.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/accessible/tests/mochitest/moz.png,v
done
Checking in accessible/tests/mochitest/moz.png;
/cvsroot/mozilla/accessible/tests/mochitest/moz.png,v  <--  moz.png
initial revision: 1.1
done

This concludes this bugfix.
Status: NEW → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.