Re: ARIA WG Guidelines to avoid scope creep (Was: article navigation)

I tried to start a wiki page, but I can't log in or reset my password.

FWIW, my user/pass combo works elsewhere on the W3C site... Just not the ARIA wiki.


> On Dec 7, 2015, at 2:20 AM, Schnabel, Stefan <stefan.schnabel@sap.com> wrote:
> 
> >>>Do other members of the ARIA group think this type of Guidelines list is worth pursuing?
>  
> The draft proposal, although very comprehensive and reasonable, lacks information regarding some important details.
>  
> Guideline 1.
>  
> “.. confusion that is not experienced by a sighted user …”
>  
> Does group consensus exist what are end user expectations and what not decide on that?
> Which external clearly defined sources can be used as respected reference in case of debates / no consensus about that?
>  
> “… such that "checked/unchecked" statuses are ambiguous to an AT user, but an "on/off" status is understandable. "Bathroom light, checked checkbox" is ambiguous where "Bathroom light, on" is not …”
>  
> The behavior here is based on assumptions and the redundancy pattern mentioned is very dependent on the context of the role. In addition, it implicitly includes discussions with AT and UA to implement, support and so on. But this is not the very point.
>  
> What about screen reader user expectations in general? ARIA IMHO always excluded “expected” speech output discussions as part of the definitions. If you want them as decision helper what to specify in the model and what not, we need a clear foundation of expected speech output for existing and also concepts for new roles as reference. I don’t see it out there that can serve as common, widely accepted standard screen reader vendors obey to, but please prove me wrong. In case you have nothing here: If you say that ARIA also should specify screen reader speech output, I would vote for that (honestly, this is what the testers need!) but then we all should eat the can of worms opened with this.
>  
> Guideline 2.
>  
> “… based on speculative future UI behavior of assistive technology.”
>  
> What if the future behavior is NOT speculative but confirmed by major AT vendors? Shouldn’t it be part of a general approach to add consistency among different platforms?
>  
> Guideline 3.
>  
> This paragraph lacks definitions what SHOULD be part of minor releases. Is it more than correcting typos, refining document structure and deprecation declarations? If so, what else is allowed?
>  
> Best Regards
> Stefan
>  
> From: Alexander Surkov [mailto:surkov.alexander@gmail.com <mailto:surkov.alexander@gmail.com>] 
> Sent: Freitag, 4. Dezember 2015 13:45
> To: James Craig <jcraig@apple.com <mailto:jcraig@apple.com>>
> Cc: public-aria@w3.org <mailto:public-aria@w3.org>; Michael Cooper <cooper@w3.org <mailto:cooper@w3.org>>; Janina Sajka <janina@rednote.net <mailto:janina@rednote.net>>
> Subject: Re: ARIA WG Guidelines to avoid scope creep (Was: article navigation)
>  
> Personally I support the idea of minor version for minor changes. Also at certain degree the guidelines reflect my worries about the growing of ARIA to replicate HTML semantics, like adding a figure role. I'm not sure I always can see an user benefit behind a new role.
>  
> On Wed, Dec 2, 2015 at 4:24 AM, James Craig <jcraig@apple.com <mailto:jcraig@apple.com>> wrote:
> (BCC PFWG list. If you want to continue this thread, join the ARIA list.)
>  
> James Craig wrote:
> 
> 
> PS. "feed" seems a out-of-scope for a 1.1 criteria, does it not? Why is a list of articles in a feed more or less semantic than a list of article outside a feed? Does the end user need to know about the difference? If not, cut it.
>  
> I'd like to make a case for extremely critical analysis of which new features make it into ARIA 1.1. My recollection is that the 1.1 release was intended to be a quick errata and oversights release, but we're nearing (over?) 2 years of work already.
>  
> I propose creating a list of guidelines the ARIA Working Group can use when considering any new role or feature. The Chair and Staff Contact should use this list of criteria to enforce scope and maintain a reasonable timeline for deliverables. I've started a first draft:
>  
> Guideline 1. If the role is a subclass (e.g. checkbox -> switch, or textbox -> searchbox), the ARIA Working Group MUST NOT add the role unless there is a significant *user* benefit to using the subclass role instead of the superclass role. Criteria to determine role worthiness may include (A) commonality of the UI (e.g. switches and search fields are extremely common in mainstream UI) and (B) determination of whether the use of the superclass role causes confusion that is not experienced by a sighted user (e.g. switch labels are often phrased such that "checked/unchecked" statuses are ambiguous to an AT user, but an "on/off" status is understandable. "Bathroom light, checked checkbox" is ambiguous where "Bathroom light, on" is not.)
>  
> Guideline 2. The ARIA Working Group SHOULD NOT add a new roles or ARIA features based on speculative future UI behavior of assistive technology. Justification: ARIA 1.0 included some features that were exposed to the API layer to achieve exit criteria, but were never completely implemented by assistive technologies. Exception: The ARIA Working Group MAY propose speculative roles and other ARIA features to support mainstream UI elements that are *unique* to the Web and unlikely to be implemented in native platform UI. (Note: I can't immediately think of a current example that would allow this exception.)
>  
> Guideline 3. For minor release numbers (e.g. ARIA 1.1), the ARIA Working Group SHOULD NOT add new features unless there is existing AT support for equivalent native platform features. In order to maintain scope and a reasonable timeline, the ARIA Working Group SHOULD postpone proposing such features until the next major release (e.g. ARIA 2.0). Justification: Exit criteria for minor version spec releases should not be delayed due to expectations of brand new platform API and AT support that could delay the spec for years.
>  
> For example, if there is no equivalent to a "feed" role on any native platform, completing it will require the spec editor to solidify prose, then require platform API reviewers to create a new role to match, then require rendering engines to support the new role, then require assistive technologies to support the user feature, before the minor release (e.g. ARIA 1.1) can finally ship. This could add years to the spec process... Not a wise goal for an .1 spec release. In my opinion, the design-by-spec-committee model also flies contrary to the goals of the W3C, which is only chartered to work on cross-platform technical standardization. 
>  
> Do other members of the ARIA group think this type of Guidelines list is worth pursuing?
>  
> Thanks,
> James

Received on Friday, 11 December 2015 07:57:56 UTC