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>; '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

(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