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

The tools to avoid scope creep are 1) the charter, and 2) the 
requirements. The charter says what the WG does in general, and some 
charters mention things the group explicitly has ruled out of scope; the 
requirements specify what a given specification intends to achieve.

The current charter is at:

http://www.w3.org/WAI/ARIA/charter

Perhaps some of the principles you propose might go in a future version 
of the charter. However, it's an incredible amount of bureaucracy to 
approve a charter, so we almost certainly wouldn't be addressing charter 
proposals until the current one expires in 2018.

Requirements, however, are something we need. When we advance further 
along the path to Recommendation, we have to answer the question "does 
this spec meet its requirements?". That's hard to answer when you don't 
have documented requirements. We have an empty shell for ARIA requirements:

https://github.com/w3c/aria/blob/master/requirements/aria-requirements.html

I have an action to set this up, which I partially completed with the 
above, but as it currently has empty content the action is still open:

https://www.w3.org/WAI/PF/Group/track/actions/1513

We will need to flesh this out reasonably soon, however, to support the 
advancement of ARIA 1.1. I think some of what you are suggesting might 
fit in there, with a couple caveats:

  * The requirements is almost certainly not a Rec-track document, so
    use of RFC2119 as you've done wouldn't work.
  * The requirements mostly says what you are trying to do with the
    spec, not what you are trying not to do. However, it can be useful
    for requirements to frame things by stating "anti-requirements",
    perhaps with an indication those would become positive requirements
    for a future version of the technology. So some of your suggestions
    might have a home there.

I think we should not publish an auxiliary document beyond the above two 
to define constraints for the Working Group. Your wording suggests, 
though perhaps I'm reading into it, that you are proposing a Rec-track 
or at least TR-oriented document. I don't think that solves any problems 
for us, given the availability of the charter and formal Requirements 
doc to address those problems. I also think RFC2119 statements should 
not be applied to Working Group process.

That said, there's nothing wrong with documenting operational 
principles. The place to start would seem to be the WG wiki:

http://www.w3.org/WAI/ARIA/wiki

If, after due discussion and refinement, the Working Group ratifies a 
consensus supporting such a document, I could add it to the resources of 
the static WG web site:

http://www.w3.org/WAI/ARIA/

Michael


On 02/12/2015 4:24 AM, James Craig 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
>
>