On Thu, Jul 26, 2018 at 8:57 PM, James Teh <j...@mozilla.com> wrote: > 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.
If there were only two browser vendors (including Mozilla) then yes your statement would be correct. However, we have (at least) four major browser vendors, and thus it is incorrect to assert that Mozilla alone could be "blocking progress" when any 2 of the other 3 browser vendors could implement something and have it exit CR. > 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. That may well be. If that is your assessment, we should add that to our Charter response and be quite upfront that we are unlikely to implement new ARIA stuff for (a few?) years, and perhaps ask (non-F.O.) for the WG to be postponed accordingly. In addition per your note about "still haven't implemented parts of ARIA 1.1, let alone ARIA 1.2.", if you know of any features in those specs which *no browser implements* we should call those out, and ask that the Charter explicitly dictate dropping them in the next version of ARIA for failure to get uptake. > 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". This is absolutely not in conflict, because as noted, 2 of the other 3 browser vendors can make progress independent of Mozilla. What we are saying is we are against any accessibility features being "standardized" for which their interoperable implementability is unproven (by anyone, not just by us). It is much worse to have something out there claiming to be a standard (a W3C Recommendation), when either no one is supporting it (hence fiction), or there is only one implementation (not a standard, because there is no interop). Tantek > 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
