The default bug view has changed. See this FAQ.

Support ARIA-based text attributes

RESOLVED FIXED in mozilla21

Status

()

Core
Disability Access APIs
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: Aaron Leventhal, Assigned: surkov)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs, {access})

unspecified
mozilla21
access
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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.
(Assignee)

Comment 1

9 years ago
(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

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

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

Comment 4

8 years ago
(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.
(Reporter)

Updated

8 years ago
Flags: wanted1.9.2?
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.
(Reporter)

Comment 6

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

So you are just exposing invalid: spelling. Or am I misunderstanding the concern?
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?
OK Marco tweeted there is usage.
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?
(Assignee)

Comment 10

8 years ago
(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.
(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.

Updated

6 years ago
Assignee: nobody → bolterbugz
Status: NEW → ASSIGNED
(Assignee)

Updated

5 years ago
Depends on: 746484
(Assignee)

Comment 12

5 years ago
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".
(Assignee)

Comment 13

5 years ago
David, you keep bug assigned. Is still valid?
Closing invalid for now.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID

Updated

5 years ago
Assignee: dbolter → nobody
(Assignee)

Comment 15

5 years ago
(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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
OK I couldn't find specifics for this bug in the spec.
(Assignee)

Comment 17

5 years ago
(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).
Thanks. I don't think I can read the spec usefully anymore. There must be a finite number of times one can read it.
(Assignee)

Comment 19

4 years ago
Created attachment 711707 [details] [diff] [review]
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
Assignee: nobody → surkov.alexander
Status: REOPENED → ASSIGNED
Attachment #711707 - Flags: review?(trev.saunders)
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.
Attachment #711707 - Flags: review?(trev.saunders) → review+
(Assignee)

Comment 21

4 years ago
(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.
(Assignee)

Comment 22

4 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/b27ce5760063
Flags: wanted1.9.2? → in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/b27ce5760063
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
You need to log in before you can comment on or make changes to this bug.