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
