Closed Bug 499892 Opened 13 years ago Closed 5 years ago

legitimize aria attribute usage on accessibles from native markup

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: surkov, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Eventually aria state attribute can be used on accessible from native markup without role attribute. This statement doesn't concern to universal aria state attributes like aria-disabled. Now we use aria-autocomplete on XUL textboxes for example (search box), however we can't use aria-multiline on it. I think we should legalize aria state attribute usage on roles coming from native markup. If it's not appropriate for ARIA then we should deny all of them (possibly including universal ones).
Alexander, is this bug about standardizing the use of all aria attributes, for usage where there is no role specified?
Summary: legalize aria attribute usage on accessibles from native markup → legitimize aria attribute usage on accessibles from native markup
(In reply to comment #1)
> Alexander, is this bug about standardizing the use of all aria attributes, for
> usage where there is no role specified?

David, right. It could be discussed with ARIA and HTML5 group to allow aria properties be used on HTML elements. Then we can bring this rule to XUL and etc making it universal.
I asked for this, actually, when I joined the PFWG. I don't understand why, but the group wanted to constrain where some of the attributes were allowed. It is really unfortunate, in my opinion.

I think there will be an opportunity in ARIA 2.0 to generalize how semantics can be combined to explain the capabilities and state of DHTML widgets. I don't think we can make big changes to 1.0 at this point.

The implementation guide currently states:

Q. Some WAI-ARIA properties are not global, and are only supported on certain roles. What should be mapped when a dependent WAI-ARIA property is used where it is not supported?
A. The user agent should act as if the WAI-ARIA property is absent, and not not map the given WAI-ARIA property through the platform accessibility API. For example, aria-checked should not be exposed as CHECKED on <div role="grid">

Note this is a "SHOULD" not a "MUST". I think we should probably clarify this specifically for usage on elements that don't have a role specified. In addition I think the phrase "where it is not supported" is vague and hard to compute.
To make this clear, I agree we should allow aria-* on elements with no role. I think this will be even more apparently useful in ARIA 2.0.
(In reply to comment #3)

> I think there will be an opportunity in ARIA 2.0 to generalize how semantics
> can be combined to explain the capabilities and state of DHTML widgets. I don't
> think we can make big changes to 1.0 at this point.

I don't mind if ARIA 2.0 development has started and we can follow it.

> The implementation guide currently states:
> 
> Q. Some WAI-ARIA properties are not global, and are only supported on certain
> roles. What should be mapped when a dependent WAI-ARIA property is used where
> it is not supported?
> A. The user agent should act as if the WAI-ARIA property is absent, and not not
> map the given WAI-ARIA property through the platform accessibility API. For
> example, aria-checked should not be exposed as CHECKED on <div role="grid">

That's reasonable I believe. I concern mostly universal ARIA properties and ARIA properties applicable to certain ARIA roles when ARIA role is absent but role from native markup corresponds to missed ARIA role. For example,

<div aria-disabled="true"> should be result of disabled state.
<input aria-autocomplete="true"> should be result of autocomplete state or
<input type="checkbox" aria-checked="true"/> should expose checked state though it's not good example I thnk.
Bug 681674 continues to use hacky ApplyARIAState approach for mapping ARIA states for native roles. We need to extend ARIA roles map to enfold native roles.
(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #3)
> I asked for this, actually, when I joined the PFWG. I don't understand why,
> but the group wanted to constrain where some of the attributes were allowed.
> It is really unfortunate, in my opinion.
> 
> I think there will be an opportunity in ARIA 2.0 to generalize how semantics
> can be combined to explain the capabilities and state of DHTML widgets. I
> don't think we can make big changes to 1.0 at this point.
> 
> The implementation guide currently states:
> 
> Q. Some WAI-ARIA properties are not global, and are only supported on
> certain roles. What should be mapped when a dependent WAI-ARIA property is
> used where it is not supported?
> A. The user agent should act as if the WAI-ARIA property is absent, and not
> not map the given WAI-ARIA property through the platform accessibility API.
> For example, aria-checked should not be exposed as CHECKED on <div
> role="grid">
> 
> Note this is a "SHOULD" not a "MUST". I think we should probably clarify
> this specifically for usage on elements that don't have a role specified. In
> addition I think the phrase "where it is not supported" is vague and hard to
> compute.
marking wontfix, I don't think there's a need to extend ARIA for XUL any longer.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.