734983 - Use element for mapping when ARIA role is abstract.

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

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

Rich reports we still expose the abstract role via MSAA string hack. For example:

<div role="landmark"> should map to SECTION but maps to "landmark".

Comment 1

[alexander :surkov (:asurkov)]

is it different from bug 734983? you talk about abstract roles but example is about landmark role

Comment 2

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

This bug and bug 734983 are the same :)

Comment 3

[alexander :surkov (:asurkov)]

I meant bug 765878

Comment 5

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

Yeah, Alexander I think we need to do this one for our spec partners. I'll take it if you agree it is a bug.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #5)
> Yeah, Alexander I think we need to do this one for our spec partners. I'll
> take it if you agree it is a bug.

I'd call it wontfix if it wouldn't be needed for them.

wontfix reason (for the record): abstract roles aren't supposed to be used on the web since they don't add any semantics thus there's no reason to burden the browser introducing a logic special for abstract roles.

Comment 7

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

OK agreed but as per IRC we think we should take this one for peace. I'll try to get to it this afternoon.

Comment 8

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

Attachment: an approach

Alexander what do you think of this approach? It prevents exposure of all invalid aria roles via the BSTR hack, not just the abstract roles. I don't think anyone will mind not having custom roles exposed through the MSAA BSTR trick, and we expose it via object attribute anyways.

Note I'm not sure what an nsDependentAtomString is... I might be making some bad assumptions here.

Comment 9

[alexander :surkov (:asurkov)]

Removing the logic introduced a while ago because of the chosen approach doesn't seem right. If you think this old days logic is not really needed nowadays then we need to do that in separate bug, asking AT vendors if they are dependent on it. Note, your patch doesn't remove landmarks role thing what makes it special.

Comment 10

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

(In reply to alexander :surkov from comment #9)

Thanks for taking a look.

> Removing the logic introduced a while ago because of the chosen approach
> doesn't seem right. If you think this old days logic is not really needed
> nowadays then we need to do that in separate bug, asking AT vendors if they
> are dependent on it.

Can you be more specific? Are you worried about made up ARIA roles not working anymore or something else?

> Note, your patch doesn't remove landmarks role thing
> what makes it special.

I'm not sure what you mean here?

What is the approach you would take in fixing this bug? I'd like to avoid string comparing all the abstract roles.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #10)
> (In reply to alexander :surkov from comment #9)
> 
> Thanks for taking a look.
> 
> > Removing the logic introduced a while ago because of the chosen approach
> > doesn't seem right. If you think this old days logic is not really needed
> > nowadays then we need to do that in separate bug, asking AT vendors if they
> > are dependent on it.
> 
> Can you be more specific? Are you worried about made up ARIA roles not
> working anymore or something else?

my concern is extensibility: if the user needs a new role then he just uses it. That should perfectly work in the case when the web page is designed for specific AT (for example JAWS + scripting) what is used by enterprise.

> > Note, your patch doesn't remove landmarks role thing
> > what makes it special.
> 
> I'm not sure what you mean here?

your example in bug description

> What is the approach you would take in fixing this bug? I'd like to avoid
> string comparing all the abstract roles.

It's a problem since at the quick glance I don't see any nice approach, keeping in mind that the bug fix is not needed by users, it makes me sad.

Comment 12

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

(In reply to alexander :surkov from comment #11)
> (In reply to David Bolter [:davidb] from comment #10)
> > (In reply to alexander :surkov from comment #9)
> > 
> > Thanks for taking a look.
> > 
> > > Removing the logic introduced a while ago because of the chosen approach
> > > doesn't seem right. If you think this old days logic is not really needed
> > > nowadays then we need to do that in separate bug, asking AT vendors if they
> > > are dependent on it.
> > 
> > Can you be more specific? Are you worried about made up ARIA roles not
> > working anymore or something else?
> 
> my concern is extensibility: if the user needs a new role then he just uses
> it. That should perfectly work in the case when the web page is designed for
> specific AT (for example JAWS + scripting) what is used by enterprise.

I think this is imaginary and edge casey. Custom roles will still be exposed via object attribute, is that enough?

> 
> > > Note, your patch doesn't remove landmarks role thing
> > > what makes it special.
> > 
> > I'm not sure what you mean here?
> 
> your example in bug description
> 
> > What is the approach you would take in fixing this bug? I'd like to avoid
> > string comparing all the abstract roles.
> 
> It's a problem since at the quick glance I don't see any nice approach,
> keeping in mind that the bug fix is not needed by users, it makes me sad.

I'm not thrilled either but to play the devil's advocate: the need can be seen as indirect. Specification interoperability can help users but it is harder to glean/measure.

I'd bet we are not breaking anyone, and hopefully we would find out during the aurora and beta cycle.

I'm not sure how to make progress if you aren't happy with the approach.

Comment 13

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

Also I still need to test the patch (blush). If you already did please let me know if it works. Maybe it doesn't? Maybe that was your landmark comment?

Comment 14

[alexander :surkov (:asurkov)]

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

> > my concern is extensibility: if the user needs a new role then he just uses
> > it. That should perfectly work in the case when the web page is designed for
> > specific AT (for example JAWS + scripting) what is used by enterprise.
> 
> I think this is imaginary and edge case. Custom roles will still be exposed
> via object attribute, is that enough?

Maybe it's edge case and maybe it's not used by anyone but it was done on purpose. If you think we shouldn't do that then please file another bug.

> I'd bet we are not breaking anyone, and hopefully we would find out during
> the aurora and beta cycle.

You know we won't. Usually we get feedback from users after few released versions, I bet we'll get feedback from enterprise much later.

> I'm not sure how to make progress if you aren't happy with the approach.

Please don't leave me holding the bag. All I said is the taken approach is a regression technically and thus we should be careful.

Comment 15

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

I understand you.

I'd be willing to do the outreach getting people to check aurora and backout if we break people. I think that would be easier than getting people to run try builds and then later asking for aurora approval to land. The ask from our friends is to get this into FF 18. The window will close fast (merge date in 4 days).

Comment 16

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

OK I tested this via accprobe. One problem with my WIP is that it clobbers the BSTR hack that exposes the element tag name...

So instead of a <div> having accRole 'div' it returns E_FAIL with this WIP. That would need to be corrected. I didn't intend to have custom ARIA roles clobber the existing tag BSTR hack here.

I'll fix that if it is worthwhile...  (?)

Comment 17

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

Trying one last time for spec fix.

Comment 18

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

Filed bug 798492 for BSTR accRole trick removal.

Comment 19

[James Teh [:Jamie]]

(In reply to David Bolter [:davidb] from comment #16)
> So instead of a <div> having accRole 'div' it returns E_FAIL with this WIP.
Fwiw, accRole should never return E_FAIL. Whether it returns a string role or an integer role will be decided in bug 798492, but it should return one or the other, not E_FAIL.

Comment 20

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

(In reply to James Teh [:Jamie] from comment #19)
> (In reply to David Bolter [:davidb] from comment #16)
> > So instead of a <div> having accRole 'div' it returns E_FAIL with this WIP.
> Fwiw, accRole should never return E_FAIL. Whether it returns a string role
> or an integer role will be decided in bug 798492, but it should return one
> or the other, not E_FAIL.

Hi Jamie. Returning E_FAIL was just preserving existing behaviour but we 'could' fix that here too.

Comment 21

[James Teh [:Jamie]]

(In reply to David Bolter [:davidb] from comment #20)
> Returning E_FAIL was just preserving existing behaviour
What existing behaviour? Afaik, accRole never currently returns E_FAIL except perhaps for defunct objects.

Comment 22

[James Teh [:Jamie]]

MSAA role strings are deprecated at best. I don't think we should put further effort into improving/tweaking these (unless we're getting rid of them altogether, bug 798492).