Closed Bug 1433891 Opened 2 years ago Closed 2 years ago

ARIA document roles should be easily distinguishable from top-level document container

Categories

(Core :: Disability Access APIs, enhancement)

Unspecified
All
enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla60
Tracking Status
firefox60 --- fixed

People

(Reporter: jdiggs, Assigned: jdiggs)

Details

Attachments

(1 file)

Given:

    data:text/html,<div role="document">foo</div>

or:

    data:text/html,<div role="graphics-document">foo</div>

The macOS mappings should be:

    AXRole: AXGroup
    AXSubrole: AXDocument
    AXRoleDescription: 'document'

as per the Core-AAM [1] and Graphics-AAM [2] respectively. These are instead being exposed as:

    AXRole: AXWebArea
    AXSubrole: <nil>
    AXRoleDescription: 'HTML Content'

[1] https://rawgit.com/w3c/core-aam/master/#role-map-document
[2] https://rawgit.com/w3c/graphics-aam/master/#role-map-graphics-document
Note that the exposure being used for the ARIA document roles is the same as the top-most document container (i.e. the accessible object whose content corresponds to what is found in the body element).

Furthermore, a similar condition can be seen in Linux: The top-most document container should be exposed as ATK_DOCUMENT_WEB; the children as ATK_DOCUMENT_FRAME (admittedly not the best platform role name, but it does make it possible to immediately distinguish non-native/ARIA documents from the native web document).

Changing the bug summary and platform accordingly.
OS: Mac OS X → All
Summary: ARIA document roles should be exposed as AXGroup; not AXWebArea → ARIA document roles should be easily distinguishable from top-level document container
Attached patch proposed patchSplinter Review
Gecko has two document roles: roles::DOCUMENT_FRAME and roles::DOCUMENT.
However, the former was not being used at all; the latter was being used
for both ARIA documents and for the native document container. We can
therefore fix this issue by repurposing the unused internal role:

* Rename the role from roles::DOCUMENT_FRAME to roles::NON_NATIVE_DOCUMENT,
  and add clarification to the doc strings in Role.h
* Ensure load events are still emitted for ARIA documents (bug 759833)
* Update the ARIA-document mochitests to reflect the above changes
* Change the ATK role mapping for roles::DOCUMENT (the native container)
  from ATK_ROLE_DOCUMENT_FRAME TO ATK_ROLE_DOCUMENT_WEB.
* On IAccessible2, map roles::NON_NATIVE_DOCUMENT to ROLE_SYSTEM_DOCUMENT.
  This should cause there to be no change in behavior for that platform.
* On macOS map roles::NON_NATIVE_DOCUMENT to NSAccessibilityGroupRole
  with a subrole of AXDocument.
Assignee: nobody → jdiggs
Attachment #8948772 - Flags: review?(surkov.alexander)
Comment on attachment 8948772 [details] [diff] [review]
proposed patch

Review of attachment 8948772 [details] [diff] [review]:
-----------------------------------------------------------------

to double check whether the change was intentional: UIA's roleDescription used to return "htmlContent" for ARIA documents.

unrelated change, but might be good to change Role() to NativeRole() in MSAA's DocAccessibleWrap::get_accValue.

I wish NON_NATIVE_DOCUMENT name was nicer, but cannot think of anything better, I was thinking of straightforward ARIA_DOCUMENT, and also considered PSEUDO_DOCUMENT and MOCK_DOCUMENT names, but not sure.

Marco, do you have anything to add?

Joanie, I believe same issue exists for DIALOGs: we also have native and ARIA ones.
Attachment #8948772 - Flags: review?(surkov.alexander)
Attachment #8948772 - Flags: review?(mzehe)
Attachment #8948772 - Flags: review+
(In reply to alexander :surkov from comment #3)
> Comment on attachment 8948772 [details] [diff] [review]
> proposed patch
> 
> Review of attachment 8948772 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> to double check whether the change was intentional: UIA's roleDescription
> used to return "htmlContent" for ARIA documents.

Yes and no. :) Yes insofar as it is my assumption that each platform's "HTML Content"-ish role is for the top-level container and not ARIA documents. The UIA mapping stated in the Core AAM is just Control Type: Document. See https://rawgit.com/w3c/core-aam/master/#role-map-document. No insofar as I do not currently have a Windows development environment and didn't explicitly touch anything specifically related to UIA. If I had a Windows environment, I would look to see what the most recent, available to external developers, version of Edge exposed.

That said, Jason Kiss has just updated HTML AAM. And I was surprised by what he put for UIA. See https://w3c.github.io/html-aam/#el-body. So I asked for a sanity check from Bogdan: https://github.com/w3c/html-aam/issues/117

> unrelated change, but might be good to change Role() to NativeRole() in
> MSAA's DocAccessibleWrap::get_accValue.

I can do that in a subsequent patch. I'll wait to find out what Bogdan and Marco say.

> I wish NON_NATIVE_DOCUMENT name was nicer, but cannot think of anything
> better, I was thinking of straightforward ARIA_DOCUMENT, and also considered
> PSEUDO_DOCUMENT and MOCK_DOCUMENT names, but not sure.

Yeah. I aimed for nicer and finally gave up. I figured you'd not like it and would give me a better idea if you had one. :) I myself had thought about ARIA_DOCUMENT, but wondered if something unforeseen would come along which would constitute a non-native, non-ARIA document for which this repurposed role would be appropriate. That was around the time I gave up. ;)

If between now and the time we get feedback from Marco and Bogdan you come up with a better idea, please mention it here and I'll make that change in a subsequent patch.
 
> Joanie, I believe same issue exists for DIALOGs: we also have native and
> ARIA ones.

True.... Plus we have the dialog element. Bah. New issue or shall I do it as part of this issue?
Attachment #8948772 - Flags: review?(mzehe) → review+
(In reply to Joanmarie Diggs from comment #4)
> (In reply to alexander :surkov from comment #3)
> > to double check whether the change was intentional: UIA's roleDescription
> > used to return "htmlContent" for ARIA documents.
> 
> Yes and no. :) Yes insofar as it is my assumption that each platform's "HTML
> Content"-ish role is for the top-level container and not ARIA documents. The
> UIA mapping stated in the Core AAM is just Control Type: Document. See
> https://rawgit.com/w3c/core-aam/master/#role-map-document. No insofar as I
> do not currently have a Windows development environment and didn't
> explicitly touch anything specifically related to UIA. If I had a Windows
> environment, I would look to see what the most recent, available to external
> developers, version of Edge exposed.
> 
> That said, Jason Kiss has just updated HTML AAM. And I was surprised by what
> he put for UIA. See https://w3c.github.io/html-aam/#el-body. So I asked for
> a sanity check from Bogdan: https://github.com/w3c/html-aam/issues/117

Yes, figure it out first, then simply file a follow-up bug. I don't see any client seriously using UIA to traverse our tree, so this can be postponed and should not hold up the rest of the good changes.

> > unrelated change, but might be good to change Role() to NativeRole() in
> > MSAA's DocAccessibleWrap::get_accValue.
> I can do that in a subsequent patch. I'll wait to find out what Bogdan and
> Marco say.

Subsequent is good, I'm all for small chunks if the changes are not strictly related to one big picture. And that one sounds to me like more code cleanup and correctness for a very specific use case.

> > Joanie, I believe same issue exists for DIALOGs: we also have native and
> > ARIA ones.
> 
> True.... Plus we have the dialog element. Bah. New issue or shall I do it as
> part of this issue?

New issue. Related yes, but different enough to warrant that.
(In reply to Marco Zehe (:MarcoZ) from comment #5)
 
> Subsequent is good, I'm all for small chunks if the changes are not strictly
> related to one big picture. And that one sounds to me like more code cleanup
> and correctness for a very specific use case.

Bug 1436340.

> > > Joanie, I believe same issue exists for DIALOGs: we also have native and
> > > ARIA ones.
> > 
> > True.... Plus we have the dialog element. Bah. New issue or shall I do it as
> > part of this issue?
> 
> New issue. Related yes, but different enough to warrant that.

Bug 1436339.
Keywords: checkin-needed
(In reply to Joanmarie Diggs from comment #4)

> > I wish NON_NATIVE_DOCUMENT name was nicer, but cannot think of anything
> > better, I was thinking of straightforward ARIA_DOCUMENT, and also considered
> > PSEUDO_DOCUMENT and MOCK_DOCUMENT names, but not sure.
> 
> Yeah. I aimed for nicer and finally gave up. I figured you'd not like it and
> would give me a better idea if you had one. :) I myself had thought about
> ARIA_DOCUMENT, but wondered if something unforeseen would come along which
> would constitute a non-native, non-ARIA document for which this repurposed
> role would be appropriate. That was around the time I gave up. ;)
> 
> If between now and the time we get feedback from Marco and Bogdan you come
> up with a better idea, please mention it here and I'll make that change in a
> subsequent patch.

What do you think about QUASI (d: resembling; seeming; virtual) or PSEUDO (d: almost, approaching, or trying to be) prefixes?
(In reply to alexander :surkov from comment #7)
 
> What do you think about QUASI (d: resembling; seeming; virtual) or PSEUDO
> (d: almost, approaching, or trying to be) prefixes?

If you're asking me specifically, I think it's an internal role, and more importantly it's *your* internal role. :) Therefore, if you would prefer QUASI, I'm happy to make that change. If so, let me know and I'll cancel the checkin-needed and do a new patch.

That said, is a non-native thing necessarily a pseudo/mock/quasi thing? Or is it one that should be seen as valid, but may need to be handled differently because it was created (and must be supported) by someone other than the code owners?
Pushed by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1564fec091b4
ARIA documents should be easily distinguishable from native ones r=marcoz
Keywords: checkin-needed
(In reply to Joanmarie Diggs from comment #8)
> (In reply to alexander :surkov from comment #7)
>  
> > What do you think about QUASI (d: resembling; seeming; virtual) or PSEUDO
> > (d: almost, approaching, or trying to be) prefixes?
> 
> If you're asking me specifically, I think it's an internal role, and more
> importantly it's *your* internal role. :) Therefore, if you would prefer
> QUASI, I'm happy to make that change. If so, let me know and I'll cancel the
> checkin-needed and do a new patch.
> 
> That said, is a non-native thing necessarily a pseudo/mock/quasi thing? Or
> is it one that should be seen as valid, but may need to be handled
> differently because it was created (and must be supported) by someone other
> than the code owners?

quasi is something fancy I'd say, while non_native is probably the most descriptive, agreed; let's go with non_native, anyway the code was landed.
https://hg.mozilla.org/mozilla-central/rev/1564fec091b4
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
You need to log in before you can comment on or make changes to this bug.