Re: text role removal

On 24/06/2016 8:10 AM, James Craig wrote:
> My objection was not to an incomplete issue being postponed to ARIA 
> 2.0. I objected to the removal of a *feature* that had been in the 
> spec for years and was already implemented in two browsers. To my 
> recollection, we never did that in ARIA 1.0. Furthermore, I'm not sure 
> there is W3C precedent for removing a feature that has already met its 
> exit criteria.
To clarify the context, ARIA 1.1 doesn't yet have exit criteria (though 
we have a draft), because it hasn't yet gone to Candidate 
Recommendation. This is instead about whether there is precedent for 
removing a feature that has two implementations (which would likely mean 
it meets the CR exit criteria later). The difference in those two takes 
on the issue seems minor but I think is significant. Complicated to 
explain why but I did want to separate the concepts.

The Process does not require that features in Working Drafts be retained 
in subsequent drafts just because they have at least two 
implementations. It would take a lot of research to find examples of 
"precedent", but I expect there are scads of examples of such features 
being removed, most of them considered unremarkable events. There are 
probably even more examples of features that were implemented but never 
made it into a spec to begin with, for various reasons.

The specification and implementation process inherently have tensions. 
The goal is for them to converge, but whether features are 
"implementation-first" or "specification-first" varies a lot between 
Working Groups, by specific feature, and over time. Another way to look 
at that is the goal of specifications is sometimes to be "descriptive" 
of implementations that already exist, and sometimes "prescriptive" with 
a goal to drive interoperable implementation, and that character can 
also be blended within a spec.

My take on the ARIA 1.0 approach was that it was largely prescriptive, 
building an accessibility technology and then seeking implementations. 
Implementations were sought earlier than what I think was usual at the 
time for prescriptive specs, and I understood that to be because of a 
need to test how realistic the features were before maturing the spec 
too much. This did lead to a situation where some features gained broad 
implementation early in the process, and then it was viewed as 
problematic to change or remove those features when re-engineering 
events happened. I felt that was a problem, but didn't push the issue 
much (I did a little) because the WG overall seemed to be ok with that 
situation.

There is no requirement that ARIA 1.1 follow the same process, although 
there could be a social expectation that it would, and that should be 
taken into account if there weren't clear statements to the contrary. I 
would characterize ARIA 1.1 as more blended between descriptive and 
prescriptive than ARIA 1.0 was, though probably still balanced on the 
prescriptive side. That's where it can be especially exasperating for an 
implementer who implemented something *because ARIA was prescribing it 
in a Working Draft* only to find it later removed. But the process 
doesn't say that can't happen, and there can be good reasons for it to 
happen.

So I can't offer any Process guidance to say the text role should or 
should not be removed after implementation. I'm not tuned into the text 
role thread enough to have technical insights to offer, but think that 
at the core your concern is not a process one, but that you see the need 
for the role and didn't want it removed. That's a purely technical 
discussion. The existence of implementations is a factor the WG should 
consider, in terms of cost of wasted implementation effort vs cost of 
keeping the role, or cost of reimplementation of a replacement feature, 
and interoperability issues if some implementers strongly support and 
others strongly oppose the feature. There isn't a formula for how those 
considerations might balance in a given circumstance, and I don't - yet 
at least - have any suggestions for this particular case.

Michael