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

We need to work out some process issues in January. A number of people,
including me, are going on vacation and I don't want this running off the
rails.

As chair, I am asking that this discussion be tabled to January.

Thank you,

Rich


Rich Schwerdtfeger



From:	Michael Cooper <cooper@w3.org>
To:	James Craig <jcraig@apple.com>, "public-aria@w3.org"
            <public-aria@w3.org>
Cc:	Janina Sajka <janina@rednote.net>
Date:	12/02/2015 09:21 AM
Subject:	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