RE: Question about ARIA 1.1 haspopup attribute

Stefan,

ARIA does have aria-menuitemcheckbox and aria-menuitemradio as was to show state information in a menu, so you could still use the menu button design pattern.

Jon


From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Wednesday, December 21, 2016 2:32 AM
To: Matt King <a11ythinker@gmail.com>; 'Bryan Garaventa' <bryan.garaventa@ssbbartgroup.com>
Cc: 'Accessible Rich Internet Applications Working Group' <public-aria@w3.org>
Subject: RE: Question about ARIA 1.1 haspopup attribute

Matt, Bryan,

Many thanks for fast reply. I'd like to ask one more thing:

>>> there are no requirements for assistive technologies to render information about aria-haspopup

Does this mean we have a two-class society regarding ARIA attributes, such like aria-checked where it is "expected" that AT renders info and such like aria-haspopup where this is in the mercy of AT to render info? I mean we should develop a common understanding here what is a "must" and what is a "may".
Not only on the API level (as it happens in the ARIA core specs) but also for AT. An overview table with musts and mays would help here.

I understand that you cannot force AT people to support things but on consultation level I feel a bit fooled telling a developer supplying a property just MAY work - know what I mean? This has also implications for QA processes, what should I tell an accessibility tester? "Oh yes we are supplying property x but AT just ignores it or interprets it differently" - my everyday reality but unacceptable in the long run.

Regards
Stefan


From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Mittwoch, 21. Dezember 2016 00:46
To: 'Bryan Garaventa' <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>
Cc: 'Accessible Rich Internet Applications Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Question about ARIA 1.1 haspopup attribute

Stefan,

I agree that such a use of aria-haspopup is consistent with the spec.

However, given there are no requirements for assistive technologies to render information about aria-haspopup, discoverability can be an issue. So, I would avoid using such menus as the sole path to critical function in a self-service application. Although, for most applications, this discoverability issue likely affects experience design for audiences other than just assistive technology users.

Given you address discoverability, I think context menus are often an awesome way to provide enhanced productivity for everyone, and signaling their availability with aria-haspopup is good practice.

Matt

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Tuesday, December 20, 2016 10:59 AM
To: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>
Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Question about ARIA 1.1 haspopup attribue

Hi,
Yes, aria-haspopup is still needed in this case, and I recommend 'true' at this point since this is the only supported value at present in ATs.

Examples of different types of controls that use this model can be seen by expanding the "ARIA Menus" button at
http://whatsock.com/tsg/#tgl-2-5<https://urldefense.proofpoint.com/v2/url?u=http-3A__whatsock.com_tsg_-23tgl-2D2-2D5&d=DQMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=0BxhugCQnfJzRt4IDNbXdsXUQN2sHAyjimHYp-l7RvQ&s=sq9RrTUjZrz_sW-kHgiL3Udc-keHICXn5oMCAD-r6-c&e=>
(Simply scroll down to the Variations links to the live demos, which include simulated and native controls like form fields as well.)

These live examples too can be downloaded directly in the archive at
https://github.com/accdc/tsg<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_accdc_tsg&d=DQMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=0BxhugCQnfJzRt4IDNbXdsXUQN2sHAyjimHYp-l7RvQ&s=aCGP4j9bkFricbRDyHXA6Gv6bc1PvtNqZrjZtVMua0Y&e=>

All the best,
Bryan

Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SSBBartGroup.com&d=DQMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=0BxhugCQnfJzRt4IDNbXdsXUQN2sHAyjimHYp-l7RvQ&s=XgpGz_ZDBi26SfYD1zFbU-OBnBM6dwutV-o5O-t7qFw&e=>

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Tuesday, December 20, 2016 2:13 AM
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Question about ARIA 1.1 haspopup attribue

Hi Matt, Bryan,

a discussion came up here how to signal to blind users that a control with an ARIA role has a custom (non-standard) context menu (a menu representing all functionality associated with a control, not a list with values).

I am not talking about menu buttons here where the aria-haspopup pattern is an integral part of the concept. I am talking about checkboxes, links etc.

Is ARIA 1.1 aria-haspopup="menu" here nevertheless aproppriate?  If not, is there annother mechanism using ARIA to indicate custom *context* menus?

Or isn't that needed since we once discussed that form elements doesn't need extra haspopup indication since they always have a (default) browser context menu associated? I mean there is a design principle "Don't report normalcy" and this I consider this relevant to be pointed out.

Best Regards + have a great christmas!
Stefan