- From: Matthew King <mattking@us.ibm.com>
- Date: Tue, 5 May 2015 11:47:41 -0700
- To: "Schnabel, Stefan" <stefan.schnabel@sap.com>
- Cc: "janina@rednote.net" <janina@rednote.net>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
- Message-Id: <201505051848.t45Imbh7006771@d03av04.boulder.ibm.com>
Stefan, thank you for the feedback.
I agree with your comments.
Per the editor's notes, all sections starting with section 3 will be
subject to major revision.
Our current focus is primarily the design patterns section. So far we have
resolved issues in about 10 of the fundamental patterns.
We will work on subsequent sections starting with the ones that are
directly referenced by the design patterns.
Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com
From: "Schnabel, Stefan" <stefan.schnabel@sap.com>
To: "janina@rednote.net" <janina@rednote.net>, W3C WAI Protocols &
Formats <public-pfwg@w3.org>,
Date: 05/05/2015 02:07 AM
Subject: RE: 48-Hour Call for Consensus (CfC): Publish "ARIA
Authoring Practices Guide" FPWD
Hi all,
please find my comments below (arranged by chapter).
Best Regards
Stefan
4.1.2 Keyboard Navigation between Widgets (tabindex)
>>> Once a widget has keyboard focus, arrow keys, Space, Enter key, or
other keyboard commands can be used to navigate the options of the widget,
change its state, or trigger an application function associated with the
widget.
- This paragraph belongs to the next chapter.
4.1.3 Keyboard Navigation within Widgets
- should include a block of general info how to navigate within list and
list like items (Arrow keys, HOME/END keys) or a link to respective
location of general concept descriptions within document (such as 2.1
Generally Applicable Keyboard Recommendations)
- should also explicitly list use cases where arrow navigation between
list-like items is NOT required (such as a "list" of buttons in toolbar)
4.1.5 Example Keyboard Operation: Radio Group/Radio
- should include an (optional) definition for [CTRL+Arrow] navigation
(navigating between arrow buttons without selecting)
4.2.6 Author-Defined Keyboard Short-Cuts or Mnemonics
>>> The XHTML 2 Working Group is currently developing a new Access Module
...
- Does this paragraph correctly reflect the actual status? Do any browsers
support the module (provide links)?
4.2.6.1 Supporting Tooltips with the Keyboard
>>> To provide simple text tooltips, the HTML title attribute should more
than suffice because the user agent will render it for tooltips.
- " more than suffice " is NOT accurate. Rendering of title attribute is
inconsistent between browsers and has its drawbacks, such as not being
enlarged when using page zoom in IE11. There is no key to open the default
browser tooltip in IE11. In addition, title attribute is handled as orphan
for non-form elements in Jaws and other screen readers, which is
absolutely inacceptable. Custom tooltips are currently the way to avoid
some of these limitations and you should emphasize that.
4.2.6.2 When Keyboard Handlers Shortcuts Steal the Keys
- You should comment on potential collisions with key hooks in AT, too.
Clearly, AT must not interfere with all the keyboard navigation control
patterns you describe, but you have to SAY that explicitly.
4.2.7.1 Steps for Defining a Logical Navigational Structure
- We have a fundamental issue regarding ARIA roles form and group.
To make it brief, say you have a nested fieldset scenario. You cannot nest
two divs with role=form since form derives from HTML concept of form and
there nesting of forms is forbidden. If you use role group instead
(related concept fieldset according to ARIA spec) you violate ARIA best
practices since according to spec group is intended for other purposes.
And AT? In Jaws landmarks dialog, labelled divs with role=form are
perfectly displayed, whereas divs with role=group aren't (since they are
no landmarks).
So bottom line: when you want to use div with role=form (not
role=region!) as nested "fieldset" replacement (which we do since it has
great benefit for logical nav structure) make clear in your text that this
is perfect, although it violates a base concept from HTML.
6.2.1 Live Region Properties and How to Use Them
- aria-busy is listed here whereas it is NOT explicitly a live region
property according to ARIA spec (section 5.2.5 Required Owned Elements).
It can, but needs not exclusively, be used within this context. For
instance, you update a part of UI you don't want ever to be a live region
(e.g. data fetching/repopulating parts of dynamic lists). Here, aria-busy
also comes in handy. There is a lack of examples for that in the APG.
A.3 Building Accessible Applications with WAI-ARIA
- The entire content of this section should be merged into the main
document and afterwards the appendix should be deleted.
-----Original Message-----
From: janina@rednote.net [mailto:janina@rednote.net]
Sent: Dienstag, 5. Mai 2015 00:33
To: W3C WAI Protocols & Formats
Subject: 48-Hour Call for Consensus (CfC): Publish "ARIA Authoring
Practices Guide" FPWD
Colleagues:
This is a Call for Consensus (CfC) to the Protocols and Formats Working
Group (PFWG) to approve a First Public Working Draft (FPWD) publication
of the "WAI-ARIA Authoring Practices Guide, Version 1.1" as requested by
the
ARIA-APG Subteam at:
http://lists.w3.org/Archives/Public/public-pfwg/2015May/0027.html
Proposed Actions
Approval of this CfC will result in the following two actions:
* We will mark the previous 1.0 heartbeat as "Obsolete"
pointing
* people instead to the current 1.1 revisions. There are no
plans
* to finish a 1.0 version of this Guide, focused on
WAI-ARIA-1.0.
* We will move to publish the document at the following URI
as our
* First Public Working Draft (FPWD) of "WAI-ARIA Authoring
* Practices Guide, Version 1.1:"
https://rawgit.com/w3c/aria/wd20150504/practices/aria-practices.html
ACTION TO TAKE
According to agreed PFWG Consensus Procedures, this CfC is now open for
objection, comment, as well as statements of support via email. Silence
will be interpreted as support, though messages of support are certainly
welcome.
Please review the candidate FPWD document at:
https://rawgit.com/w3c/aria/wd20150504/practices/aria-practices.html
If you object to this proposed action, or have comments concerning this
proposal, please respond by replying on list to this message no later
than 23:59 (Midnight) Boston Time, Thursday 7 May.
Janina
--
Janina Sajka, Phone: +1.443.300.2200
sip:janina@asterisk.rednote.net
Email: janina@rednote.net
Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org
The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf
Indie UI
http://www.w3.org/WAI/IndieUI/
Received on Tuesday, 5 May 2015 18:49:14 UTC