Re: Firefox bug regarding aria-readonly

Bryan et al.,

The root problem with respect it to @aria-readonly vs @readonly is due 
to how the attributes are defined.

HTML5 uses presence/absence for boolean values.  The presence of 
@readonly indicates that an <input> is read-only, whereas its absence 
means the <input> is not read-only.

ARIA uses explicit true/false assignments.  If an element is meant to be 
read-only vs. not read-only, authors write "aria-readonly='true'" vs. 
"aria-readonly='false'", respectively.

The problem occurs with the following markup (the example Bryan 
provided), where the HTML @readonly is absent.  As far as HTML5 is 
concerned, this <input> is *not* read-only:

<!-- Does not set readonly state -->
<input type="text" title="Test 4" aria-readonly="true" />

Thus we have an odd conflict where, at first blush, it looks like the 
markup is defining a read-only situation.  To avoid this mistake, an 
author has to consciously make an effort and recall that the *lack* of 
@readonly means it isn't read-only.

Worse, this *was* the only way to declare a read-only state using HTML4, 
since there is no native @readonly attribute in HTML4 -- authors had to 
use @aria-readonly.  The above example is correct for HTML4.  One 
wonders how much legacy HTML4/ARIA code is now broken.  Note that ARIA 
1.0 was written with HTML4 in mind -- there are test cases in our test 
harness [1] that passed because they were run before @readonly was 
implemented by browsers; but likely no longer pass.

FWIW, note that it requires an author to make an effort to add the 
@aria-readonly="true" to the <input>.  Even though the author has 
technically made an error and introduced a conflict, it still looks like 
they intended to make the <input> read-only, doesn't it?

I think there is an issue in tracker and a prior discussion about this, 
but I couldn't find it this morning.  I'll keep looking.

> Does this include any other attributes besides aria-readonly, 
> aria-disabled, and aria-required?

Generally, there is a conflict issue for every HTML5 attribute that, 
first, matches the semantics of an aria-* attribute, and, secondly, uses 
the presence/absence technique.  At least one other has a different 
value space, namely, @aria-autocomplete vs. @autocomplete.

[1] https://www.w3.org/WAI/PF/testharness/


On 2014-09-29 8:04 AM, Richard Schwerdtfeger wrote:
>
> No. The ARIA attribute overrides the native in the a11y tree. It is up 
> to the author to do the right thing.
>
> Rich
>
> Sent from my iPad
>
> On Sep 28, 2014, at 9:54 PM, Bryan Garaventa 
> <_bryan.garaventa@whatsock.com_ <mailto:bryan.garaventa@whatsock.com>> 
> wrote:
>
> Thanks, I’ll CC James too since he can be aware of this thread 
> regarding Safari too.
>
>
>
> So, just so I’m perfectly clear and don’t spread inaccurate 
> information to others when trying to explain this, all of the state 
> modifiers such as aria-readonly, aria-disabled, aria-required, and any 
> other that has a native attribute equivalent is going to be removed 
> from the browser accessibility tree mappings within native form fields 
> and links in the future?
>
>
>
> Does this include any other attributes besides aria-readonly, 
> aria-disabled, and aria-required?
>
>
>
> *From:*Richard Schwerdtfeger [_mailto:schwer@us.ibm.com_]
> *Sent:*Sunday, September 28, 2014 4:52 PM
> *To:*Bryan Garaventa
> *Cc:*'Alexander Surkov'; _clown@alum.mit.edu_ 
> <mailto:clown@alum.mit.edu>; _cyns@microsoft.com_ 
> <mailto:cyns@microsoft.com>; 'David Bolter'; 'Marco Zehe'; 
> _faulkner.steve@gmail.com_ <mailto:faulkner.steve@gmail.com>
> *Subject:*RE: Firefox bug regarding aria-readonly
>
>
>
> Hi Bryan,
>
> response below between <rich> and </rich>
>
> Best,
> Rich
>
> Rich Schwerdtfeger
>
> <image001.gif>"Bryan Garaventa" ---09/28/2014 01:30:14 PM---I think I 
> see what you mean, so to make certain that I understand, native active 
> elements should not
>
> From: "Bryan Garaventa" <_bryan.garaventa@whatsock.com_ 
> <mailto:bryan.garaventa@whatsock.com>>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: "'Alexander Surkov'" <_asurkov@mozilla.com_ 
> <mailto:asurkov@mozilla.com>>, "'David Bolter'" <_dbolter@mozilla.com_ 
> <mailto:dbolter@mozilla.com>>, "'Marco Zehe'" <_marco.zehe@gmail.com_ 
> <mailto:marco.zehe@gmail.com>>, <_clown@alum.mit.edu_ 
> <mailto:clown@alum.mit.edu>>, <_cyns@microsoft.com_ 
> <mailto:cyns@microsoft.com>>
> Date: 09/28/2014 01:30 PM
> Subject: RE: Firefox bug regarding aria-readonly
>
> ------------------------------------------------------------------------
>
>
>
>
> I think I see what you mean, so to make certain that I understand, 
> native active elements should not include ARIA state modifiers in 
> place of natively supported state modifiers?
>
> <rich>yes</rich>
> E.G
>
> <input type=”text” readonly />
>
> And
>
> <div tabindex=”0” role=”textbox” aria-readonly=”true” 
> contenteditable></div>
>
> So ARIA is valid on one but not the other?
>
> <rss>ARIA is valid on both. However, if you have a native readonly set 
> and then apply aria-readonly="false" you have a conflict. The readonly 
> is equivalent to aria-readonly="true">
>
> What does this mean for native active elements that don’t support 
> native state modifiers though?
>
> E.G
>
> <a href=”#” disabled > Link that is styled as being disabled </a>
>
> The above markup will not set the unavailable state in IE or FF, 
> however the following will.
>
> <a href=”#” aria-disabled=”true” > Link that is styled as being 
> disabled </a>
>
> <rich>This is a bug in IE and FF. See the HTML5 specification under 
> section 3.2.7.1. It clearly states:
> "Element that is disabled The aria-disabled state set to 'true'"
>
> This is why we have native host language semantics in HTML and SVG. 
> This is also why we should have had an HTML implementation guide that 
> was normatively specified for HTML5. We have not clearly proven 
> accessibility implementation. This was the type of problem I told 
> people we would have but we could not address until HTML 5.1 and ARIA 
> 1.1. We are doing that now.
>
> So, I think we all appreciate your frustration Bryan and we are 
> working to correct these inconsistencies. So, although HTML5 is going 
> out I believe the truly interoperable version will be the one aligned 
> with ARIA 1.1 where we will normatively specified accessibility API 
> mapping specifications.
>
> I will also tell you that we are making VERY GOOD progress on the Core 
> Accessibility API spec. and the HTML5 and SVG specs. are right on its 
> heals as they are dependent on the Core specification. This was the 
> strategy we all agreed to for the mapping specs. I don't know what 
> ARIA 2.0 will look like but this will be good for what we need for the 
> near future.
>
> I am cc'ing Steve to make sure he sees this mapping issue with 
> unavailable. Thanks for raising the issue Bryan.
>
>
> </rich>
>
> So would this be a browser bug too?
>
> <rich>yes. per above.</rich>
>
>
> *From:* Richard Schwerdtfeger [_mailto:schwer@us.ibm.com_]
> *Sent:* Sunday, September 28, 2014 9:33 AM
> *To:* Bryan Garaventa
> *Cc:* Alexander Surkov; David Bolter; Marco Zehe; _clown@alum.mit.edu_ 
> <mailto:clown@alum.mit.edu>; _cyns@microsoft.com_ 
> <mailto:cyns@microsoft.com>
> *Subject:* Re: Firefox bug regarding aria-readonly
>
>
> 1. It is mapped to a11y Apis as read only.
> 2. IE needs to fix its bugs. We should not be coding to bugs. Read 
> only has been in ARIA for years.
> 3. The author should make sure it behaves as read only. If there is a 
> conflict it as author error.
>
> Thee reason we have these issues is we gave a copy of the aria spec. 
> to Hixie years ago and he folded many of the features in to html 5.
>
> To avoid these conflicts authors should use the built in readonly state.
>
> Rich
>
>
>
> Sent from my iPad
>
> > On Sep 27, 2014, at 11:05 PM, Bryan Garaventa 
> <_bryan.garaventa@whatsock.com_ <mailto:bryan.garaventa@whatsock.com>> 
> wrote:
> >
> > That's a good idea, I've also CCd Rich and Cynthia too, since 
> aria-readonly and aria-disabled does work correctly in IE, setting 
> both the readonly and unavailable state for each.
> >
> > The question to all here from me, if aria-readonly is not supposed 
> to set the readonly state on a form field, how are ATs supposed to 
> know that the state is readonly when interfacing with this object in 
> the accessibility tree?
> >
> > -----Original Message-----
> > From: Alexander Surkov [_mailto:asurkov@mozilla.com_]
> > Sent: Saturday, September 27, 2014 7:48 PM
> > To: Bryan Garaventa
> > Cc: David Bolter; Marco Zehe; _clown@alum.mit.edu_ 
> <mailto:clown@alum.mit.edu>
> > Subject: Re: Firefox bug regarding aria-readonly
> >
> > Sure, I bet we have some special processing for aria-disabled and we 
> don't have it for aria-readonly. My concern is how much we do it 
> correctly. Maybe we should fix aria-disabled rather than 
> aria-readonly. CC'ing Joseph.
> >
> >
> > ----- Original Message -----
> > From: "Bryan Garaventa" <_bryan.garaventa@whatsock.com_ 
> <mailto:bryan.garaventa@whatsock.com>>
> > To: "Alexander Surkov" <_asurkov@mozilla.com_ 
> <mailto:asurkov@mozilla.com>>, "David Bolter" <_dbolter@mozilla.com_ 
> <mailto:dbolter@mozilla.com>>
> > Cc: "Marco Zehe" <_marco.zehe@gmail.com_ <mailto:marco.zehe@gmail.com>>
> > Sent: Saturday, September 27, 2014 3:14:00 PM
> > Subject: RE: Firefox bug regarding aria-readonly
> >
> > Technically they should both set the same state, readonly when one 
> or the other is present.
> >
> > This actually does occur when aria-disabled='true' is a applied to a 
> form field, setting the unavailable state correctly in FF in the same 
> manner as the disabled attribute.
> >
> > -----Original Message-----
> > From: Alexander Surkov [_mailto:asurkov@mozilla.com_]
> > Sent: Saturday, September 27, 2014 10:23 AM
> > To: David Bolter
> > Cc: Bryan Garaventa; Marco Zehe
> > Subject: Re: Firefox bug regarding aria-readonly
> >
> > What ARIA says nowadays, should it override native state when is in 
> conflict?
> >
> > ----- Original Message -----
> > From: "David Bolter" <_dbolter@mozilla.com_ 
> <mailto:dbolter@mozilla.com>>
> > To: "Bryan Garaventa" <_bryan.garaventa@whatsock.com_ 
> <mailto:bryan.garaventa@whatsock.com>>
> > Cc: "Marco Zehe" <_marco.zehe@gmail.com_ 
> <mailto:marco.zehe@gmail.com>>, _asurkov@mozilla.com_ 
> <mailto:asurkov@mozilla.com>
> > Sent: Saturday, September 27, 2014 12:02:05 PM
> > Subject: Re: Firefox bug regarding aria-readonly
> >
> > Cc+ surkov
> >
> > Bryan Garaventa <_bryan.garaventa@whatsock.com_ 
> <mailto:bryan.garaventa@whatsock.com>> wrote:
> >
> > Hi guys,
> > I'm not sure where to send this, so I figured I'd just pass it along 
> directly.
> >
> > Basically, in Firefox, the readonly attribute on a form field will 
> set the 'readonly' state in the accessibility tree, however 
> aria-readonly='true' will not.
> >
> > Example:
> >
> > <!-- Sets readonly state -->
> > <input type="text" title="Test 3" readonly />
> >
> > <!-- Does not set readonly state -->
> > <input type="text" title="Test 4" aria-readonly="true" />
> >
> > All the best,
> > Bryan
> >
> >
> >


-- 
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -

Received on Monday, 29 September 2014 15:18:08 UTC