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
(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

All the best,
Bryan

Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Tuesday, December 20, 2016 2:13 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: 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