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

James,

Facebook is the MOST widely used application in the  industry with over 1
Billion users and more people use this application world wide than
virtually anything else. One of the issues up front was to address an issue
whereby we needed a dynamic list. If you recall Matt King asked very early
for the ability to identify a list as a list was too restrictive. Twitter
also has a feed so if you add that the number of people that would be using
this feature is huge. Also, most mobile operating systems add special
features to better integrate Facebook and Twitter into them -iOS included.
The group reconciled on addressing this by introducing a feed. There is
nothing speculative about this and waiting for an ARIA 2.0, which will be a
very long time out is not acceptable. Countless hours were spent before and
after TPAC for which you made no comments on prior and during TPAC.
Unfortunately, addressing the issue took a long time. The feed is a very
simple way to do that and I would argue there is nothing speculative about
it.

If we were going to be critical I would say the most unnecessary addition
to ARIA 1.1 was Switch. This could be represented as a checkbox.  It does
not take a rocket scientist to determine that if you had Lights checked or
not checked to determine that the lights are being turned on or off. In my
mind we bent the rules to do it but like the dynamic list it was identified
as an issue at the start if ARIA 1.1. That is my opinion but obviously the
group agree to put it in.

ARIA 2.0 is going to be a much bigger animal and it will require us to look
at a lot of things including integration with an actual API that will allow
for device independent interaction.

I don't thint that feed is a huge add to a platform. In particular articles
are already supported by platforms. We are talking about one container role
that indicates that the list of articles can be infinite and it tells the
user that they will have the abiltity to navigate amont the articles (what
we asked for in the dynamic list in the first paragraph) in the first few
months of doing ARIA 1.1.

So, I disagree that this was not something we had asked for at the
beginning. I don't agree that it it is out of scope.

This is not a giant addition to ARIA. All the platforms already support
article. Firefox already implemented posinset and setsize on articles. All
this is is a container that says the list is dynamic.

A critical thing that needs to be addressed for any release, no matter how
minor, is can we actually afford to wait for 3-4 years for another release
for a feature.

Rich


Rich Schwerdtfeger



From:	James Craig <jcraig@apple.com>
To:	"public-aria@w3.org" <public-aria@w3.org>
Cc:	Michael Cooper <cooper@w3.org>, Janina Sajka
            <janina@rednote.net>
Date:	12/02/2015 03:25 AM
Subject:	ARIA WG Guidelines to avoid scope creep (Was: article
            navigation)



(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