RE: Mapping @aria-invalid: string versus token value

Apparently this varies with the type of field and way of marking it up.

I get the following results.

<h2>aria-required and aria-invalid tests</h2>

<p>A field marked with aria-required. JAWS correctly announces it as 
required.</p>
<span id="fooFieldLabel">Foo:</span>
<input aria-labeledby="FooFieldLabel" aria-required="true" 
aria-invalid="false" type="text" />

<p>A field marked invlaid and not required. JAWS correctly announces it as 
invalid.</p>
<span id="barFieldLabel">Bar:</span>
<input aria-labeledby="barFieldLabel" aria-required="false" 
aria-invalid="true" type="text" />

<p>A field marked invlaid and required. JAWS correctly announces it as 
both required and invalid.</p>
<span id="beerFieldLabel">Beer:</span>
<input aria-labeledby="beerFieldLabel" aria-required="true" 
aria-invalid="true" type="text" />

<p>Search input mark as required using HTML 5 markup. JAWS incorrectly 
announces it as both required and invalid.</p>
<input title="Search" required type="search" placeholder="Search">

<p>HTML 5 search field marked invalid. JAWS correctly announces it as 
invalid.</p>
<input title="Search" aria-invalid="true" type="search" 
placeholder="Search">

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To:     Matthew King/Fishkill/IBM@IBMUS, 
Cc:     Joseph Scheuhammer <clown@alum.mit.edu>, James Craig 
<jcraig@apple.com>, PF <public-pfwg@w3.org>, "Schnabel, Stefan" 
<stefan.schnabel@sap.com>
Date:   07/29/2014 10:30 AM
Subject:        RE: Mapping @aria-invalid: string versus token value



Afraid not, I just tested the following:
 
<input title="Search" required type="search" placeholder="Search">
 
This is announced in JAWS as “required invalid entry”
 
The Accessibility Tree object State in Firefox is as follows for this 
field “FOCUSED FOCUSABLE ALERT_LOW ALERT_HIGH”.
And this is what it is for IE11: “FOCUSED FOCUSABLE”
 
As opposed to the following markup:
 
<input title="Search" aria-invalid="true" type="search" 
placeholder="Search">
 
Which has the following State in Firefox: “FOCUSED FOCUSABLE ALERT_HIGH”
And this in IE11: “FOCUSED FOCUSABLE ALERT_HIGH”.
 
So the State of ALERT_HIGH for both required=true and aria-invalid=true in 
FF causes JAWS to announce “invalid” for both.
 
From: Matthew King [mailto:mattking@us.ibm.com] 
Sent: Tuesday, July 29, 2014 10:13 AM
To: Bryan Garaventa
Cc: Joseph Scheuhammer; James Craig; PF; Schnabel, Stefan
Subject: RE: Mapping @aria-invalid: string versus token value
 
When fields are marked required, JAWS is saying required. 
When they are marked invalid, JAWS is saying invalid. 
When they have both,I am pretty sure it is saying both ... need to verify 
that. 
This is with Firefox 31. 
I wonder what is behind the difference in our experiences. 

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com 



From:        Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> 
To:        "Schnabel, Stefan" <stefan.schnabel@sap.com>, Matthew 
King/Fishkill/IBM@IBMUS, 
Cc:        James Craig <jcraig@apple.com>, Joseph Scheuhammer <
clown@alum.mit.edu>, PF <public-pfwg@w3.org> 
Date:        07/29/2014 09:28 AM 
Subject:        RE: Mapping @aria-invalid: string versus token value 




I understand, what I was referring to is that both states are the same in 
the Accessibility  Tree, one for when required=”true”, and the same for 
when aria-invalid=”true”, so both are announced as being “invalid” by 
screen readers like JAWS. 
  
I was wondering if this was intentional. 
  
  
From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] 
Sent: Tuesday, July 29, 2014 12:03 AM
To: Bryan Garaventa; Matthew King
Cc: James Craig; Joseph Scheuhammer; PF
Subject: RE: Mapping @aria-invalid: string versus token value 
  
I’m not absolutely sure what you mean, HTML5 @required maps to 
aria-required=true. 
aria-invalid is for state processing afterwards. 
  
Regards 
Stefan 
  
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Dienstag, 29. Juli 2014 07:34
To: Schnabel, Stefan; Matthew King
Cc: James Craig; Joseph Scheuhammer; PF
Subject: RE: Mapping @aria-invalid: string versus token value 
  
I was running a couple of tests, and was curious about something. 
  
Should the required attribute have the same state as aria-invalid=”true” 
on a blank input? 
  
E.G Both of the following have a state of “ALERT_HIGH” in Firefox. 
  
<input title="Search" required type="search" placeholder="Search"> 
  
<input title="Search" aria-invalid="true" type="search" 
placeholder="Search"> 
  
  
From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] 
Sent: Monday, July 28, 2014 9:51 PM
To: Matthew King
Cc: James Craig; Joseph Scheuhammer; PF
Subject: Re: Mapping @aria-invalid: string versus token value 
 
In addition, we could extend the list of allowed tokens (enumerations) 
with more members that represent typical other cases when errors or other 
kind of messages are thrown as a result of user actions in form fields. 
 
as i said yesterday, "warning" and "info" are candidates to indicate the 
nature of the severity level although their meaning could collide a bit 
with the "invalid" meaning of the very attribute. 
 
as rich ( ?) pointed out yesterday, an general "aria-messagelevel" 
attribute may be better here.. this can be associated with an eLement 
having a Aria role=message which makes the whole thing much more 
straightforward. message then can become either a popup or reside in a 
live region (message bar) 
 
Thoughts? 
 
- Stefan

Sent from my iPad 

On 28.07.2014, at 21:31, "Matthew King" <mattking@us.ibm.com> wrote: 
Agree, we should only have string values where the expected behavior is 
for the AT to speak the string, e.g., aria-label. Otherwise it should be 
an ID or some enumerated value. 

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com 



From:        James Craig <jcraig@apple.com> 
To:        PF <public-pfwg@w3.org>, 
Cc:        Joseph Scheuhammer <clown@alum.mit.edu> 
Date:        07/28/2014 12:03 PM 
Subject:        Mapping @aria-invalid: string versus token value 





@aria-invalid is a token value, but as Joseph pointed out today, the UAIG 
instructs user agents to map string values to the platform APIs. I think 
this is an error in the UAIG, even if some (or all) of the implementations 
are doing it. 

Free-form string tokens mean some AT could start providing special 
behavior for a non-standardized value. For example: JAWS could start using 
"warning-length" versus NVDA supporting "size-warning" to mean the same 
thing. I'd like to avoid the inconsistencies of the "browser war" years, 
so I don't think this possibility should exist.

Thoughts?