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