Re: 48-Hour Call for Consensus (CfC): Publish "ARIA Authoring Practices Guide" FPWD

+1 to the CFC.

To Steffan. All great points, thanks for taking the time to post these comments.
We are definitely not there and we will publish a number of other
dafts over the coming months until we reach a full 1.1 final spec.
As you can see, many sections in this document have an editors note
saying that they were imported as is, from the 1.0 document and have
not been reviewed yet.
We will take a look at all the comments you posted.
Incidentally, I wonder why I never seem to be able to type "points"
correctly at first, I always write "pints".
Thanks
-B



On 5/5/15, Schnabel, Stefan <stefan.schnabel@sap.com> wrote:
> 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 12:19:03 UTC