Closed
Bug 453321
Opened 17 years ago
Closed 16 years ago
ARIA role of "application" not exposed correctly as ROLE_SYSTEM_APPLICATION.
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: MarcoZ, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(3 files)
snapshot of accexplorer output showing role text: application
The code snippet:
<body class="tundra" role="application">
should cause Firefox to expose the accessible's role as ROLE_SYSTEM_APPLICATION, but only the string role of "application" is exposed.
|
||
Comment 1•17 years ago
|
||
|
|
||
Comment 2•17 years ago
|
||
Comment on attachment 336654 [details]
Testcase -- only fails when I run it from my hard drive.
Must be some kind of timing issue.
Attachment #336654 -
Attachment description: Testcase → Testcase -- only fails when I run it from my hard drive.
|
Reporter | |
Comment 3•17 years ago
|
||
It also fails for me if I open it from the attachments list.
|
||
Comment 4•17 years ago
|
||
(In reply to comment #0)
> should cause Firefox to expose the accessible's role as
> ROLE_SYSTEM_APPLICATION, but only the string role of "application" is exposed.
Sorry, what does it mean?
|
|
||
Comment 5•17 years ago
|
||
msaa/nsAccessibleWrap::get_accRole() returns a BSTR for the role, using the role attribute. That's wrong. It should be returning ROLE_SYSTEM_APPLICATION.
|
|
||
Comment 6•17 years ago
|
||
|
|
||
Comment 7•17 years ago
|
||
David & Joseph, does role="application" ever work in a Dojo app?
|
|
||
Comment 8•17 years ago
|
||
Also, if you link to Dojo 1.2 instead, that doesn't help.
|
||
Comment 9•17 years ago
|
||
Comment on attachment 341906 [details]
Even smaller testcase -- appears that just using Dojo at all makes it fail
I'm seeing an exposed role of "application" using AccExplorer 2.0.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2) Gecko/2008090514 Firefox/3.0.2
(An FF auto-update is downloading in the background; this is on my VMWare XP Pro)
|
|
||
Comment 10•17 years ago
|
||
|
|
||
Comment 11•17 years ago
|
||
(In reply to comment #10)
> Created an attachment (id=341920) [details]
> snapshot of accexplorer output showing role text: application
A question: what does accexplorer show when dojo is not included in the script tags in the header? The same?
|
|
||
Comment 12•17 years ago
|
||
(In reply to comment #11)
> (In reply to comment #10)
> > Created an attachment (id=341920) [details] [details]
> > snapshot of accexplorer output showing role text: application
>
> A question: what does accexplorer show when dojo is not included in the script
> tags in the header? The same?
Yes.
|
|
||
Comment 13•17 years ago
|
||
David, did you try saving testing it after saving the test file locally?
|
|
||
Comment 14•17 years ago
|
||
(In reply to comment #13)
> David, did you try saving testing it after saving the test file locally?
Yes.
|
|
||
Comment 15•17 years ago
|
||
This gets stranger...
Aaron, I can confirm your testcase (smaller one) when Firebug is disabled and I run it locally. Running locally with Firebug enabled shows application role properly. I haven't been able to confirm the problem when loading remotely. Aaron, have you tried your smaller test case running remotely?
|
|
||
Comment 16•17 years ago
|
||
David, it's probably timing-related.
|
|
||
Updated•16 years ago
|
Flags: blocking1.9.2?
|
|
||
Comment 17•16 years ago
|
||
Marco is this one still alive?
|
|
Reporter | |
Comment 18•16 years ago
|
||
Can no longer reproduce in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090210 Minefield/3.2a1pre. Please reopen if you encounter this issue again.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
|
||
Updated•16 years ago
|
Flags: blocking1.9.2?
You need to log in
before you can comment on or make changes to this bug.
Description
•