798492 - Deprecate/Remove our Windows MSAA BSTR accRole hack

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P3)

Description

[David Bolter [:davidb] (NeedInfo me for attention)]

The BSTR hack was deemed a worthy role extensibility mechanism while MSAA-only AT were abundant. We need to find out if vendors are now relying on it, or at least if they can stop replying on it. We can simply use IA2+ (or UIA) extension mechanisms.

This was spun off of bug 734983 and related discussion with Rich regarding ARIA conformance, but at least for now let's see if we can make it about the totality of the BSTR accRole hack/trick.

It might be ambitious given the vendor outreach needed but let's target FF 19. We can probably put the fix behind a config option.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Note, a Microsoft person has asked me a few times (over the years) that we stop doing this.

I suspect it makes their MSAA->UIA bridge technology vomit a little bit.

Comment 2

[alexander :surkov (:asurkov)]

David, do you take this bug? If so then please cc me to emails to at vendors.

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Yes I should probably take this one of the plate. Taking...

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

I'm using these to come up with the right MSAA roles:
http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html
http://msdn.microsoft.com/en-us/library/windows/desktop/dd373608%28v=vs.85%29.aspx

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: WIP

First quick pass at replacing MSAA stringy roles.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Try build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-31bb7e7abdb3/try-win32/

Comment 7

[James Teh [:Jamie]]

David, I saw your email, but figured it made more sense to respond here. :)

NVDA always uses the IA2 role in preference to the MSAA role as long as retrieving the IA2 role doesn't fail and it isn't IA2_ROLE_UNKNOWN. This means that most of the time, we never even see the BSTR role hack, so this change won't affect us. Unfortunately, I do know that Gecko sometimes fails to map the "object" and "embed" tags correctly to IA2_ROLE_EMBEDDED_OBJECT. I can't remember whether it returns IA2_ROLE_UNKNOWN or fails, nor was I ever able to figure out exactly when this happens. To make matters worse, I recall that this was intermittent even with the same test case.

So, in short, this shouldn't affect us. The one case where it will affect us is "embed" and "object" tags, but that's another bug anyway. The only caveat is that this embed bug will need to be fixed rather urgently if it does show up after the BSTR role hack is removed.

Mick, please comment if you think I've missed anything.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to James Teh [:Jamie] from comment #7)

> So, in short, this shouldn't affect us. The one case where it will affect us
> is "embed" and "object" tags, but that's another bug anyway. The only caveat
> is that this embed bug will need to be fixed rather urgently if it does show
> up after the BSTR role hack is removed.

Thanks Jamie. I think we could leave the "embedded object" string for now - is that the one you are referring to?

Comment 9

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #8)
> (In reply to James Teh [:Jamie] from comment #7)
> 
> > So, in short, this shouldn't affect us. The one case where it will affect us
> > is "embed" and "object" tags, but that's another bug anyway. The only caveat
> > is that this embed bug will need to be fixed rather urgently if it does show
> > up after the BSTR role hack is removed.
> 
> Thanks Jamie. I think we could leave the "embedded object" string for now -
> is that the one you are referring to?

I lean towards to do nothing here because:
# the behavior is in use
# we can't suggest anything better for role mapping, that'll be either unknown role or generic role
# it doesn't really fix the bug 734983 since when 'xml-roles' attribute is standardized by IA2 group (I filed request a while ago and iirc nobody objected it) then it becomes a "standard role mechanism" and we break the spec again.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to alexander :surkov from comment #9)
> (In reply to David Bolter [:davidb] from comment #8)
> > (In reply to James Teh [:Jamie] from comment #7)
> > 
> > > So, in short, this shouldn't affect us. The one case where it will affect us
> > > is "embed" and "object" tags, but that's another bug anyway. The only caveat
> > > is that this embed bug will need to be fixed rather urgently if it does show
> > > up after the BSTR role hack is removed.
> > 
> > Thanks Jamie. I think we could leave the "embedded object" string for now -
> > is that the one you are referring to?
> 
> I lean towards to do nothing here because:
> # the behavior is in use
> # we can't suggest anything better for role mapping, that'll be either
> unknown role or generic role
> # it doesn't really fix the bug 734983 since when 'xml-roles' attribute is
> standardized by IA2 group (I filed request a while ago and iirc nobody
> objected it) then it becomes a "standard role mechanism" and we break the
> spec again.

I think I understood and agree with the first two bullets, but not sure I understand the last one. Is it about the MSAA BSTR role hack or about object attributes (or both)? Can you explain a bit more?

Comment 11

[James Teh [:Jamie]]

(In reply to David Bolter [:davidb] from comment #8)
> Thanks Jamie. I think we could leave the "embedded object" string for now -
> is that the one you are referring to?
I've never seen "embedded object", only "embed" and "object" depending on the tag.

(In reply to alexander :surkov from comment #9)
> I lean towards to do nothing here because:
> # the behavior is in use
Arguably, it's only in use because Gecko doesn't expose IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.

> # we can't suggest anything better for role mapping, that'll be either
> unknown role or generic role
True, but that's probably the case for many of the BSTR roles. Otherwise, the hack wouldn't have been introduced in the first place.

> # it doesn't really fix the bug 734983 since when 'xml-roles' attribute is
> standardized by IA2 group (I filed request a while ago and iirc nobody
> objected it) then it becomes a "standard role mechanism" and we break the
> spec again.
I should find that thread. Imo, xml-roles doesn't fit the IA2 spec, since it is HTML specific. I don't follow what you mean about breaking the spec again, though.

Comment 12

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #10)

> I think I understood and agree with the first two bullets, but not sure I
> understand the last one. Is it about the MSAA BSTR role hack or about object
> attributes (or both)? Can you explain a bit more?

I referred to 'xml-roles' object attributes what is I think you are agree is a role mechanism. If it would be a standard one then it means we shouldn't use it to expose abstract roles.

Comment 13

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #11)

> (In reply to alexander :surkov from comment #9)
> > I lean towards to do nothing here because:
> > # the behavior is in use
> Arguably, it's only in use because Gecko doesn't expose
> IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.

it should be our bug and it should be fixed. Btw, would you mind to file a bug?

> > # it doesn't really fix the bug 734983 since when 'xml-roles' attribute is
> > standardized by IA2 group (I filed request a while ago and iirc nobody
> > objected it) then it becomes a "standard role mechanism" and we break the
> > spec again.
> I should find that thread. Imo, xml-roles doesn't fit the IA2 spec, since it
> is HTML specific.

I cannot find it. Maybe I was confused.

> I don't follow what you mean about breaking the spec
> again, though.

My point was is 'xml-roles' object attribute is a role mechanism. ARIA spec denies us to expose ARIA abstract roles via "standard role mechanism". I read that as any role mechanism of every AT API spec shouldn't be used to expose abstract roles. While xml-roles is a Firefox feature then probably we won't be pushed about changing existing behavior of xml-roles.

Refer to (http://www.w3.org/WAI/PF/aria-implementation/#mapping_role):
"For the standard role mechanism of the accessibility API, the user agent MUST use the first token in the sequence of tokens in the role attribute value which matches, on comparison, the name of any non-abstract WAI-ARIA role."

Comment 14

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #13)
> > Arguably, it's only in use because Gecko doesn't expose
> > IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.
> it should be our bug and it should be fixed. Btw, would you mind to file a
> bug?
I could, but I haven't because I don't have any useful information at this point. It looks like this might have been a work around for Firefox 3.6, so it's possible this has been fixed since then.

Comment 15

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to alexander :surkov from comment #12)
> (In reply to David Bolter [:davidb] from comment #10)
> 
> > I think I understood and agree with the first two bullets, but not sure I
> > understand the last one. Is it about the MSAA BSTR role hack or about object
> > attributes (or both)? Can you explain a bit more?
> 
> I referred to 'xml-roles' object attributes what is I think you are agree is
> a role mechanism. If it would be a standard one then it means we shouldn't
> use it to expose abstract roles.

As per IRC I'd like this bug to be scoped to the MSAA role string hack. Microsoft has asked us not to do this and if it is not going to horribly break AT then I'd like to try to remove it.

Comment 16

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to James Teh [:Jamie] from comment #14)
> (In reply to alexander :surkov from comment #13)
> > > Arguably, it's only in use because Gecko doesn't expose
> > > IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.
> > it should be our bug and it should be fixed. Btw, would you mind to file a
> > bug?
> I could, but I haven't because I don't have any useful information at this
> point. It looks like this might have been a work around for Firefox 3.6, so
> it's possible this has been fixed since then.

Hi Jamie, any update? It would be nice to remove the hack entirely.

Comment 17

[James Teh [:Jamie]]

(In reply to David Bolter [:davidb] from comment #16)
> > > > Arguably, it's only in use because Gecko doesn't expose
> > > > IA2_ROLE_EMBEDDED_OBJECT sometimes when it should.
> Hi Jamie, any update? It would be nice to remove the hack entirely.
I really don't remember how to reproduce this at all. I guess go ahead and remove it and I'll file a bug if I see the problem again.

Comment 18

[David Bolter [:davidb] (NeedInfo me for attention)]

[Note to self: one of the related w3 actions https://www.w3.org/WAI/PF/Group/track/actions/1175]

Comment 19

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: kill_bstr_hack

Clean try run: https://tbpl.mozilla.org/?tree=Try&rev=22cb1df5ef89

Comment 20

[James Teh [:Jamie]]

(In reply to David Bolter [:davidb] from comment #19)
> Clean try run: https://tbpl.mozilla.org/?tree=Try&rev=22cb1df5ef89
I don't understand how to get from these URLs to the actual builds.

Comment 21

[Trevor Saunders (:tbsaunde)]

(In reply to James Teh [:Jamie] from comment #20)
> (In reply to David Bolter [:davidb] from comment #19)
> > Clean try run: https://tbpl.mozilla.org/?tree=Try&rev=22cb1df5ef89
> I don't understand how to get from these URLs to the actual builds.

under the heading [e-mail] or similar there should be link with text "b" click on that then area should up with link to "build directory" which should include firefox.zip I believe.

Comment 22

[David Bolter [:davidb] (NeedInfo me for attention)]

Builds are here http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-22cb1df5ef89/

Comment 23

[David Bolter [:davidb] (NeedInfo me for attention)]

Jamie, note I wasn't expecting you to test these builds - do debug builds work for you?

Comment 24

[James Teh [:Jamie]]

(In reply to David Bolter [:davidb] from comment #23)
> Jamie, note I wasn't expecting you to test these builds - do debug builds
> work for you?
They normally don't. Let me know if/when you want me to test a normal build.

Comment 25

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks. Non-debug build will show up here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-fa56af7cd553

Comment 26

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 787643 [details] [diff] [review]
kill_bstr_hack

Let me know what you think of the mappings. I think it makes sense to try to keep close to IE since MSAA is less useful (thank IA2) for most of these cases anyway. The other good thing is that we already expose the tag as an object attr anyways.

Hopefully this brings us into ARIA spec compliance.

Comment 27

[alexander :surkov (:asurkov)]

It seems it something new with me. Didn't we talk to stop ARIA roles mapping into BSTR only?

Comment 28

[alexander :surkov (:asurkov)]

(In reply to alexander :surkov from comment #27)
> It seems it something new with me. Didn't we talk to stop ARIA roles mapping
> into BSTR only?

maybe it shouldn't be new with me per my comments in this bug :) but I completely missed that we wanted to go further than ARIA roles removing. Can you remind me details please?

Comment 29

[David Bolter [:davidb] (NeedInfo me for attention)]

I can't remember. I know we talked about both options. We can limit to aria only at least initially. I'll update.

Comment 30

[David Bolter [:davidb] (NeedInfo me for attention)]

Alexander finally looked at doing this and it would be a less nice patch, which reminds me of a chat where I think I got your approval on going further here. Want to chat again?

Comment 31

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #30)
> Alexander finally looked at doing this and it would be a less nice patch,

removing ARIA only you mean? it should be a simple patch

> which reminds me of a chat where I think I got your approval on going
> further here. Want to chat again?

yep, btw does Chrome copy us here?

Comment 34

[James Teh [:Jamie]]

Attachment: Bug 798492: Don't return BSTR from IAccessible::get_accRole.

This is a hack that was implemented a long time ago before IAccessible2.
However, it violates the MSAA API, breaks Microsoft's Inspect tool and violates the Core/HTML AAM specs.
In terms of backwards compatibility, anyone who wants to really access web content will be using IAccessible2 anyway.
Also, Chromium has never implemented this hack.

The mappings were largely taken from the Core and HTML AAM specs.
Where those specs didn't specify an MSAA role, ROLE_SYSTEM_GROUPING has been used, which is the closest we can get to a generic mapping and is also used by Chromium for these cases.

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8a84e76f7bb0
Don't return BSTR from IAccessible::get_accRole. r=nlapre

Comment 36

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/8a84e76f7bb0