445510 - Support ARIA-based text attributes

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

Currently we only have aria-invalid. If it's present, not-empty and not "false" then we should expose it as the "invalid" text attribute for the range it's on.

In the future (perhaps for ARIA 2), there will likely be more, in order to support ARIA-based word processors.

Comment 1

[alexander :surkov (:asurkov)]

(In reply to comment #0)
> Currently we only have aria-invalid. If it's present, not-empty and not "false"
> then we should expose it as the "invalid" text attribute for the range it's on.
> 
> In the future (perhaps for ARIA 2), there will likely be more, in order to
> support ARIA-based word processors.
> 

for the aria-invalid="value" we should expose text attribute "invalid: value", right?

Comment 2

[Marco Zehe (:MarcoZ)]

(In reply to comment #1)
> for the aria-invalid="value" we should expose text attribute "invalid: value",
> right?

Correct!

Comment 3

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

Is this bug up to date? From a quick skim it looks like test_textattrs.html includes a text attribute test for invalid: spelling.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #3)
> Is this bug up to date? From a quick skim it looks like test_textattrs.html
> includes a text attribute test for invalid: spelling.

David, but iirc we don't expose aria-invalid to text attributes. Probably we should change bug summary to reflect this.

Comment 5

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

OK. I'm thinking it is not ideal that we would expose both invalid:spelling as well as aria-invalid:spelling, but perhaps that is most robust.

Comment 6

[Aaron Leventhal]

Strip off aria- when turning it into a text attribute.

So you are just exposing invalid: spelling. Or am I misunderstanding the concern?

Comment 7

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

Right, okay, so we can arrive at invalid: spelling through aria or through gecko's inline spell checker.

I'm trying to figure out the priority of this bug; any evidence of usage in the wild?

Comment 8

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

OK Marco tweeted there is usage.

Comment 9

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

Values of aria-invalid are:

grammar:  A grammatical error was detected.
false:    There are no detected errors in the value.
spelling: A spelling error was detected.
true:     The value entered by the user has failed validation.

Our current non-aria implementation nsHyperTextAccessible::GetTextAttributes, checks:

spelling
language
CSS-based attributes

I'm wondering how we want to combine/reconcile these. Do we want to completely bail on our existing implementation if aria-invalid is present?

Comment 10

[alexander :surkov (:asurkov)]

(In reply to comment #9)

> I'm wondering how we want to combine/reconcile these. Do we want to completely
> bail on our existing implementation if aria-invalid is present?

ARIA always wins - that's paradigm iirc.

Comment 11

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

(In reply to comment #10)
> (In reply to comment #9)
> 
> > I'm wondering how we want to combine/reconcile these. Do we want to completely
> > bail on our existing implementation if aria-invalid is present?
> 
> ARIA always wins - that's paradigm iirc.

Yes I agree. I wonder though, if there is an aria-invalid="true" which means value failed validation, and our spell check finds a spelling error, it might be nice to expose both (aria-invalid via obj attr) and (spelling invalid via text attr). Maybe that's just silly.

Comment 12

[alexander :surkov (:asurkov)]

we need to fix bug 746484 because we can't implement the bug until we have proper mechanism to work with multivalue text attributes.

consider:
<input aria-invalid="grammar" value="smoe misspeled ttext>
at 0 offset we should expose "invalid:grammar,spelling".

Comment 13

[alexander :surkov (:asurkov)]

David, you keep bug assigned. Is still valid?

Comment 14

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

Closing invalid for now.

Comment 15

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #14)
> Closing invalid for now.

huh, I meant validness of bug assignee status, not the bug status. The bug itself is valid, at least ARIA spec requires us to do that.

Comment 16

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

OK I couldn't find specifics for this bug in the spec.

Comment 17

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #16)
> OK I couldn't find specifics for this bug in the spec.

see aria-invalid at http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property_table:

aria-invalid="true", "spelling", or "grammar" (state)	Set IA2_STATE_INVALID_ENTRY.
Expose the value as a text attribute (not object attribute).

Comment 18

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

Thanks. I don't think I can read the spec usefully anymore. There must be a finite number of times one can read it.

Comment 19

[alexander :surkov (:asurkov)]

Attachment: patch

basic implementation of aria-invalid mapped to invalid text attribute.

1) we don't support aria-invalid inheritance and token list for aria-invalid until the ARIA spec clearly address that
2) invalid:spelling text attribute coming from builtin spellchecker overrides aria-invalid values, again until the spec says something about values conflict resolving

Comment 20

[Trevor Saunders (:tbsaunde)]

Comment on attachment 711707 [details] [diff] [review]
patch

the true and false values are weird and I'm not sure what they're supposed to mean, but whatever they mean I guess just reflecting them is fine.

>+TextAttrsMgr::InvalidTextAttr::
>+  GetValueFor(Accessible* aAccessible, uint32_t* aValue)
>+{
>+  nsIContent* elm = nsCoreUtils::GetDOMElementFor(aAccessible->GetContent());

it seems like it would be good to add accessible->Element() for this sort of thing.

Comment 21

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #20)
> Comment on attachment 711707 [details] [diff] [review]
> patch
> 
> the true and false values are weird and I'm not sure what they're supposed
> to mean, but whatever they mean I guess just reflecting them is fine.

I agree they seems useless, also any unknown value mapping to 'true' is weird as well, I would just expose that value AT to let them decide.

> >+TextAttrsMgr::InvalidTextAttr::
> >+  GetValueFor(Accessible* aAccessible, uint32_t* aValue)
> >+{
> >+  nsIContent* elm = nsCoreUtils::GetDOMElementFor(aAccessible->GetContent());
> 
> it seems like it would be good to add accessible->Element() for this sort of
> thing.

it can be confusing, AssociatedElement() perhaps. It can be gfb.

Comment 22

[alexander :surkov (:asurkov)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/b27ce5760063

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b27ce5760063