- From: Schnabel, Stefan <stefan.schnabel@sap.com>
- Date: Tue, 29 Jul 2014 07:02:36 +0000
- To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, Matthew King <mattking@us.ibm.com>
- CC: James Craig <jcraig@apple.com>, Joseph Scheuhammer <clown@alum.mit.edu>, PF <public-pfwg@w3.org>
- Message-ID: <323C3CDA661E2E489F372903A1B2A7946C3D5B9A@DEWDFEMB10C.global.corp.sap>
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<mailto: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<mailto:mattking@us.ibm.com> From: James Craig <jcraig@apple.com<mailto:jcraig@apple.com>> To: PF <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, Cc: Joseph Scheuhammer <clown@alum.mit.edu<mailto: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?
Received on Tuesday, 29 July 2014 07:03:28 UTC