That all seems reasonable from a process perspective. The only thing worth noting is that while you say there's no need to delay for years, that may well be what ends up happening, and Mozilla will essentially be "blocking progress" on this front. We want "limited resources" to drive better standards, yet with our resources in accessibility as limited as they are at this point, it's entirely likely we won't get around to implementing new ARIA stuff for years. At that point, we have a conflict: we have Mozilla objecting to the minimum implementation exception, while at the same time not resourcing accessibility sufficiently to make any reasonable progress at all. I'm not sure we can have it "both ways".
Jamie On Fri, Jul 27, 2018 at 11:27 AM, Tantek Çelik <tan...@cs.stanford.edu> wrote: > On Thu, Jul 26, 2018 at 6:04 PM, James Teh <j...@mozilla.com> wrote: > > On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron <dba...@dbaron.org> > wrote: > > > >> So some comments on the ARIA charter at > >> https://www.w3.org/2018/03/draft-aria-charter : > >> ... > >> I guess it seems OK to have only one implementation > >> if there's really only going to be one implementation on that > >> platform... but allowing it in general (i.e., seems less than ideal, > > > > It is. However, the problem is that accessibility in general is severely > > lacking in resources across browser vendors (especially Mozilla!; we're > > currently working with just 2 engineers). Even where browser vendors > agree > > on how something *should* be done, it often takes months or years before > it > > gets implemented, primarily due to the aforementioned resource shortage. > We > > (Mozilla) still haven't implemented parts of ARIA 1.1, let alone ARIA > 1.2. > > The reality is that if multiple implementations were required for > sign-off, > > it'd probably delay the process for years. > > Respectfully, I disagree with that use of process, and those > unimplemented parts of ARIA 1.1, let alone ARIA 1.2 should probably > have been dropped and/or postponed to future versions. > > The reality is that if a standard does not reflect what is > implemented/implementable (and yes, economic constraints / costs, > resource are a legitimate reason to criticize something as not being > implementable), then it should not be in the standard. > > A better answer when something lacks multiple implementations is: > 1. if there is only one implementation, move it to an informative > (non-normative) appendix > 2. if there are zero implementations, cut it and postpone it to the > next +0.1 version > > By following such a methodology, there is no need to delay "for > years". You ship the spec (go to PR) with what happens to be supported > as of that point in time, then work on the next +0.1 version to ship > the next year and repeat, hopefully increasing the number of features > that are interoperable implemented. > > > and > >> allowing only 75% of mappings to be implemented to count as > >> success seems pretty bad. > >> > > Same issue as above regarding limited resources. Still, this one is a > > little more concerning because it raises questions about whether the > > remaining 25% will *ever* be implementable. > > Right, same issue with implementability, and same answer (1, 2 above). > > We (especially Mozilla) want "limited resources" to be a forcing > function to drive better standards, simpler to implement, test, debug, > secure, etc. > > No user benefits from unimplemented standards. > > If anything, such "specifiction" causes harm in that it can cause > false expectations of what "works", wasting web developer time and > resources. > > Tantek > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
