Re: ARIA 1.1: primary button attribute proposal

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