RE: Agenda: February 3, 2014 WAI-PF ARIA Caucus

Hi Stefan,

I will add it to the discussion. The challenge we will have is that OS
platforms do not currently separate out special help for keyboard. There is
also the issue for mobile devices where when we look at IndieUI the
keyboard handling could be passed off to the browser.

Rich


Rich Schwerdtfeger



From: "Schnabel, Stefan" <stefan.schnabel@sap.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, W3C WAI Protocols &
            Formats <public-pfwg@w3.org>
Date: 02/03/2014 02:48 AM
Subject: RE: Agenda: February 3, 2014 WAI-PF ARIA Caucus



My apologies for today .. conflicting meeting.

Rich, please mention the following:

Regarding Issue 406

- https://www.w3.org/WAI/PF/Group/track/issues/406


I’d like to add that this property can serve as invaluable source of
information source for custom keyboard usage infos as part of the UI DOM
(e.g. containing strings like “Press F4 to open extended input options”).

We highly want and need this since these cases are frequent in our
products.

Additionally, this property offers a potential “correcting” option with
respect to implementation of known patterns/roles and AT misassumptions how
to use them. A prominent example is the Jaws “Press Ctrl+Tab to move
between tabs” assumption for role=”tablist” but the tablist navigation is
implemented using Arrow keys to move between tabs for good reasons. So, the
Jaws info would be misleading and there is no way to fix it without
actively quering the UA aria-help property mapping by AT (e.g. using the
MSAA accHelp string property).

But probably the best design here would be an additional

aria-keyhelp (string)

property to indicate AT that this role/element/control has implemented its
own custom keyboard behavior and AT should leave its “guesses” based on the
role and just speak what the respective property.

The mapping of this property (if present) should be done together with the
aria-help property (if present) as concatenation of both string values into
the e.g. MSAA accHelp property.

Regards
Stefan


From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Sonntag, 2. Februar 2014 20:16
To: W3C WAI Protocols & Formats
Subject: Agenda: February 3, 2014 WAI-PF ARIA Caucus



Agenda: February 3, 2014 WAI-PF ARIA Caucus

Time of meeting is 10:00AM EST, 14:00 UTC, duration is 1.5 hours
Zakim Bridge +1.617.761.6200, conference 92473 ("WAIPF")

IRC: server: irc.w3.org, port: 6665, channel: #aria.

- Identify Scribe
- ARIA 1.0 Actions Cleanup:
https://www.w3.org/WAI/PF/Group/track/products/1

- Discuss new meeting time

- ARIA 1.1 Meaty Issues
- Issue 348" ARIA Phased in alternative for role="presentation"
  - https://www.w3.org/WAI/PF/Group/track/issues/348

  - Extensive Discussion:
https://lists.w3.org/Archives/Member/w3c-wai-pf/2014JanMar/

- Issues 411, 406 Addition of aria-description or aria-help
- https://www.w3.org/WAI/PF/Group/track/issues/411

- https://www.w3.org/WAI/PF/Group/track/issues/406


- ARIA 1.1 Less Meaty Issues
- Issure 435: Role=text https://www.w3.org/WAI/PF/Group/track/issues/435

- Issue 446: Role=switch with on/off state
https://www.w3.org/WAI/PF/Group/track/issues/446



References:

ARIA Test Plan Action Items:
http://www.w3.org/WAI/PF/Group/track/products/5


ARIA Open Actions and Issues:
https://www.w3.org/WAI/PF/Group/track/products/1


UAIG Open Actions and Issues:
https://www.w3.org/WAI/PF/Group/track/products/10


ARIA Test Report:
https://www.w3.org/WAI/PF/testharness/testreport?testsuite_id=1


Use Cases for Extended Descriptions:
http://www.w3.org/WAI/PF/wiki/Use_Cases_for_Extended_Descriptions


ARIA 1.1 Open Actions and Issues:
https://www.w3.org/WAI/PF/Group/track/products/17


Minutes Last Meeting(s):
http://www.w3.org/2014/01/25-aria-minutes.html
http://www.w3.org/2014/01/24-aria-minutes.html

http://www.w3.org/2014/01/23-aria-minutes.html



Rich Schwerdtfeger