Open Bug 798492 Opened 8 years ago Updated 3 years ago

Deprecate/Remove our Windows MSAA BSTR accRole hack

Categories

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

x86
Windows 7
defect

Tracking

()

People

(Reporter: davidb, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
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.
David, do you take this bug? If so then please cc me to emails to at vendors.
Yes I should probably take this one of the plate. Taking...
Assignee: nobody → dbolter
Whiteboard: Needs vendor outreach
Attached patch WIP (obsolete) — Splinter Review
First quick pass at replacing MSAA stringy roles.
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.
(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?
(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.
(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?
(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.
(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.
(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."
(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.
(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.
(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.
(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.
Whiteboard: Needs vendor outreach → Needs vendor outreach [update and land may 15 for test buffer]
Flags: needinfo?(dbolter)
Whiteboard: Needs vendor outreach [update and land may 15 for test buffer]
(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.
(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 dbolter@mozilla.com 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.
Jamie, note I wasn't expecting you to test these builds - do debug builds work for you?
(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 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.
Attachment #787643 - Flags: review?(surkov.alexander)
It seems it something new with me. Didn't we talk to stop ARIA roles mapping into BSTR only?
(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?
I can't remember. I know we talked about both options. We can limit to aria only at least initially. I'll update.
Attachment #787643 - Flags: review?(surkov.alexander)
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?
(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?
Assignee: dbolter → nobody
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.