RE: Question about ARIA 1.1 haspopup attribute

Matt, Bryan,

You guys are doing a super job to back up the APG with all the examples planned .
I understand the situation and I agree that elaborated examples are the first step for cross-AT compliance.
I believe one these examples have been carefully scrutinized be AT, braowser and control developers many of the existing issues can be addressed.

As I did in the past I do offer some testing services for the combinations FF/IE + JAWS/NVDA as soon as the new example suite is completely online.
I am always open for discussions about this and can give input what is needed from a business perspective, too.

Let's hope with the increased number of AT developers involved we can get an even better overall WAI-ARIA coverage in 2017!

Best Regards
Stefan

From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Mittwoch, 21. Dezember 2016 21:22
To: Schnabel, Stefan <stefan.schnabel@sap.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

Stefan wrote:
>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.

Stefan, that is a good choice of words, "expected". I would say that we have assistive technology expectations of some kind for all attributes, including haspopup, but there is no such thing as an ARIA compliant assistive technology. That, as you know, is a long-standing working group decision about the scope of the ARIA specification. Of course, it is a decision that was made and revisited at specific points in time and made for very practical reasons that considered the landscape at those times. Whether or not there has been sufficient change in the landscape to justify reconsideration is a very good question.

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

Yesk, very, very well.

This is one reason Rich has been working hard to get more participation from assistive technology developers. But, it is very difficult for them to balance effective participation in web standards and requirements with the rest of their business.

We believe we will have more AT developer participation in 2017.

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

Yes, unacceptable in the long run.

BTW, normative requirements for AT are not the only feasible approach to changing this reality. To start with, we have not even had authoritative reference implementations of ARIA that can be used by assistive technology developers. That is a huge, I believe primary, reason for the massive inconsistency. And, that is why I am so heavily invested in filling the gap with the authoring practices guide.

Matt

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Wednesday, December 21, 2016 12:32 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: 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
(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<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com<http://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<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