- From: Matthew King <mattking@us.ibm.com>
- Date: Tue, 19 May 2015 11:09:21 -0700
- To: "Gunderson, Jon R" <jongund@illinois.edu>
- Cc: W3C WAI Protocols & Formats <public-pfwg@w3.org>, "Richard Schwerdtfeger" <schwer@us.ibm.com>, Alexander Surkov <surkov.alexander@gmail.com>
- Message-Id: <201505191810.t4JIAQ8q013891@d03av04.boulder.ibm.com>
John, I do not think a generic, concrete widget role will help; it could make things worse. For all practical purposes, you can already do that with role application ... and it is problematic. 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: "Gunderson, Jon R" <jongund@illinois.edu> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, Cc: W3C WAI Protocols & Formats <public-pfwg@w3.org>, Alexander Surkov <surkov.alexander@gmail.com> Date: 05/19/2015 07:11 AM Subject: RE: aria-interactive and the authoring/debug process problems I suggest creating a ROLE=INTERACTIVE as a generic role to indicate an interactive element that cannot be described with current ROLE values. Use ARIA labeling techniques to give the role and name/label and use aria-describedby to give a description of the interaction behavior. Jon From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] Sent: Monday, May 18, 2015 4:37 PM To: Gunderson, Jon R Cc: W3C WAI Protocols & Formats; Alexander Surkov Subject: RE: aria-interactive and the authoring/debug process problems We also need this for SVG. We will have interactive parts of SVG drawings. Rich Schwerdtfeger "Gunderson, Jon R" ---05/14/2015 04:40:07 PM---Alexander, It may be a good step toward custom roles, but is the wider web community ready for that From: "Gunderson, Jon R" <jongund@illinois.edu> To: Alexander Surkov <surkov.alexander@gmail.com> Cc: W3C WAI Protocols & Formats <public-pfwg@w3.org> Date: 05/14/2015 04:40 PM Subject: RE: aria-interactive and the authoring/debug process problems Alexander, It may be a good step toward custom roles, but is the wider web community ready for that step, will it make it easier or harder for development groups to understand and implement ARIA correctly? Should this step be part of ARIA 1.1 when there are so many ARIA authoring issues with just ARA 1.0? If anything I believe part of ARIA 1.1 should be trying to simplify and clarify the use of roles, properties, states and accessible name/description calculation, not making it more complex. Jon From: Alexander Surkov [mailto:surkov.alexander@gmail.com] Sent: Thursday, May 14, 2015 4:05 PM To: Gunderson, Jon R Cc: W3C WAI Protocols & Formats Subject: Re: aria-interactive and the authoring/debug process problems I think of aria-interactive as one step forward to custom roles since it is a way to describe roles. I think I agree that new widget - new role approach would be preferable as the new role is completely spec'd out and reusable, but it probably doesn't work for the web diversity. To address the authoring errors problem, we may not allow to override interactive value on certain roles. 14 мая 2015 г. 3:35 PM пользователь "Gunderson, Jon R" < jongund@illinois.edu> написал: I understand the desire to reduce the number of roles in ARIA, but I have concerns that using aria-interactive attribute to achieve this goal will probably be detrimental to learning, authoring and debugging. Think of people looking at a DOM inspector and it says role=?gridcell?, but the accessibility API represents it as role=?td?. What role does a validation or visualization tool report to the user (e.g. GRIDCELL or TD)? If it is TD then the developer will not find a role=?td? in their DOM inspector view If it is gridcell then the definition of gridcell has to be more complicated to discuss that it is sometimes interactive and sometimes static based on an ancestor role of aria-interactive. It sounds simple, but I think this will cause a lot of authoring errors, debugging problems and messaging complexity. I think role values should not be able to switch between interactive and non-interactive based on attribute values, that should be a fundamental part of a role. ARIA is hard enough for developers to understand, making some roles change from interactive to non-interactive based on attribute values will add to the complexity of learning and using ARIA. My two cents, Jon
Attachments
- image/gif attachment: 01-part
Received on Tuesday, 19 May 2015 18:11:07 UTC