- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Thu, 10 Dec 2015 11:22:46 -0500
- To: James Craig <jcraig@apple.com>
- Cc: Alexander Surkov <surkov.alexander@gmail.com>, James Nurthen <james.nurthen@oracle.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
On 2015-12-08 2:50 AM, James Craig wrote: > On Dec 7, 2015, at 7:31 AM, Joseph Scheuhammer<clown@alum.mit.edu> wrote: >> > >> >Hi James, >> > >> >On 2015-12-04 9:45 PM, James Craig wrote: >>>> >>>n Dec 4, 2015, at 12:31 PM, Joseph Scheuhammer<clown@alum.mit.edu> wrote: >>>>> >>> > >>>>> >>> >On 2015-12-04 8:07 AM, Alexander Surkov wrote: >>>>>>> >>>> >>I agree that ARIA would benefit of having a way to provide the semantics of a default button. I would replace though a long aria-primaryaction name on short aria-default. That would look like: >>>>>>> >>>> >> >>>>>>> >>>> >><div role='button' aria-default> >>>>>>> >>>> >> >>>>>>> >>>> >>The naming is similar to MSAA's STATE_SYSTEM_DEFAULT state exposed on default buttons. >>>>> >>> > >>>>> >>> >Similarly, ATK_STATE_DEFAULT [1] and ATSPI_STATE_IS_DEFAULT [2]. >>>>> >>> > >>>>> >>> >OS X has an AXDefaultButton property, but, there, it's a property of the AXDialog, not the button itself. (Note: determined via the Accessibility Inspector). >>> >>The ARIA equivalent would be an IDREF attr on a dialog, pointing to one of the contained buttons. >>> >> >>> >><div role="dialog" aria-labelledby="label_text" aria-default="cancel_button"> >>> >> <h1 id="label_text">Are you sure you want to delete your irreplaceable photos?</h1> >>> >> <button>Delete</button> >>> >> <button id="cancel_button">Cancel</button> >>> >></div> >>> >> >> >Brain-storming ahead: >> > >> >This feels like a special case of aria-controls, where the default button controls the acceptance and/or dismissal of the dialog/landmark. A possibility along those lines is to have @aria-default as in your example above pointing from the dialog to the button, and add @aria-controls on the default button to establish the controller-for/controlled-by relationship between the button and the enclosing dialog. >> > >> >The problem with that is it invites author errors. > Yes, this is getting pretty complicated. Yes, I'm inclined to reject my line of thought, and support your IDREF proposal. That approach has the advantage that mappings are possible in IA2, ATK and AXAPI. For IA2 and ATK, the browser follows the IDREF, and sets the "default state" on the accessible button associated with the referenced element with role button. For AXAPI, the IDREF approach is isomorphic with the usage of the AXDefaultButton reference from the associated AXDialog. > > Assuming we went back to the original proposal, what behavioral AT differences are expected when adding @aria-primaryaction? Do Windows or Linux screen readers give a different role description or activation behavior for this button? Orca generates a speech for a dialog: "Default button is <name of button>". It does this by searching for the accessible button that has the "default state" within the accessible dialog. I don't know about NVDA nor JAWS. What do OS X ATs do with the AXDefaultButton property? > > James > > PS. If so, could the same behavior be achieved using @role and @aria-roledescription? I suppose, but if the AT is already using the AAPI "default state" on the desktop, as Orca does, it would make sense for them to continue using the same technique when it comes to ARIA default buttons. Would AXAPI stop using AXDefaultButton and choose to use AXRole and AXRoleDescription instead? Or continue to use AXDefaultButton on the desktop but use AXRole/AXRoleDescription for web apps? Usually a proposal for a new aria role, state, or property leads to a lengthy discussion within the UAI task force about how to map it to the various AAPIs in an interoperable manner. This is a case where three of the AAPIs already provide mappings that fit with the proposal. I'd be surprised if UIA didn't have a "default button control pattern" or something like that to support default buttons. And I may yet be surprised. One problem is that the proposed aria-primaryaction (or aria-default) is associated with landmarks as well as dialogs. I presume that's because role="form" and role="search" often have a default action associated with them, like dialogs; and because form and search are landmark roles. Remove the association with landmarks in general, but allow it on elements with form and search aria roles. -- ;;;;joseph. 'Array(16).join("wat" - 1) + " Batman!"' - G. Bernhardt -
Received on Thursday, 10 December 2015 16:23:20 UTC