Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-27 Thread Tantek Γ‡elik
LGTM. Thanks David. -t

On Fri, Jul 27, 2018 at 12:26 PM, L. David Baron  wrote:
> I submitted comments on both charters:
>
> https://lists.w3.org/Archives/Public/public-new-work/2018Jul/0016.html
> https://lists.w3.org/Archives/Public/public-new-work/2018Jul/0015.html
>
> (I'm still able to revise them in the next 8 hours if there's
> something that needs to be modified.)
>
> -David
>
> --
> π„ž   L. David Baron http://dbaron.org/   𝄂
> 𝄒   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-27 Thread L. David Baron
I submitted comments on both charters:

https://lists.w3.org/Archives/Public/public-new-work/2018Jul/0016.html
https://lists.w3.org/Archives/Public/public-new-work/2018Jul/0015.html

(I'm still able to revise them in the next 8 hours if there's
something that needs to be modified.)

-David

-- 
π„ž   L. David Baron http://dbaron.org/   𝄂
𝄒   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-27 Thread James Teh
A final clarification:

On Fri, Jul 27, 2018 at 4:36 PM, Tantek Γ‡elik 
wrote:

> Even if we (Mozilla) are delayed with implementation, we can
> still champion this stuff. We can still nominate someone to
> participate in the WG with subject matter expertise to help guide what
> we think will be more implementable features.
>
1.  Superficially (I haven't dug into it in detail), I don't believe
anything proposed in ARIA 1.1 or 1.2 is likely to be "not implementable" or
even "costly to implement" for browser vendors. It's more that the Mozilla
accessibility team currently doesn't have anyone who can devote time to
working on new spec things. To put it melodramatically, with current
resourcing, it's likely to take us months to even get to reading the spec
or implement the simplest of spec additions. I really hope this does not
remain the case for too long, but that's how it is right now.
2. For the same reason, we also don't have anyone with subject matter
expertise that's able (due to tie constraints) to participate meaningfully
in the WG.

Jamie
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread L. David Baron
I also have a few comments on the draft APA charter at
https://www.w3.org/2018/03/draft-apa-charter now that I've had a
chance to review it.

I think we should suggest that both:
 * the first toplevel bullet point in the scope section
 * the second bullet point in the success criteria section
be more explicitly open about working with non-W3C groups, since I
think there may be productive opportunities for such interaction,
such as with the WHATWG.

This is also the first time I'm seeing the work on Personalization
Semantics.  I wonder whether it's a good idea for this work to have
its naming such that it's essentially limited to accessibility,
since many of the semantics being defined seem more generally useful
for cases beyond accessibility (e.g., they'd be very helpful for
autofill).  I wonder if they should be more general additions to the
markup languages being extended rather than accessibility-specific
attributes (at least based on what I think the naming is suggesting).

I'm curious what others think about this, particularly the latter
point.

-David

-- 
π„ž   L. David Baron http://dbaron.org/   𝄂
𝄒   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread Tantek Γ‡elik
On Thu, Jul 26, 2018 at 10:48 PM, James Teh  wrote:
> TL;DR: Thanks for the further explanation/clarification. I (reluctantly)
> agree that these concerns make sense and have nothing else to add as far as
> the response goes.

Thanks Jamie.  I very much appreciate your thoroughness. The
additional details you provided below can help us with our charter
response.


> On Fri, Jul 27, 2018 at 2:33 PM, Tantek Γ‡elik 
> wrote:
>>
>> > 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.
>
> That's fair. I suppose there's some (now irrelevant) historical context
> here: it used to be that Mozilla championed this stuff and drove others to
> push accessibility forward. At present, that is not the case, and I'm
> concerned it'll now be very hard to make much progress in accessibility.
> Still, while that's kind of sad, I take your point that this is irrelevant
> to the requirements of the charter.

Got it. Even if we (Mozilla) are delayed with implementation, we can
still champion this stuff. We can still nominate someone to
participate in the WG with subject matter expertise to help guide what
we think will be more implementable features.


>> > 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.
>
> Honestly, there is a lot of uncertainty at this point; I certainly couldn't
> give any "formal" statement concerning what we might or might not implement.
> FWIW, I believe Mozilla *should* implement this stuff, but that all depends
> on me convincing leadership that we should provide more resources for
> accessibility. :) Again, irrelevant to our charter response.

Perhaps we can write a comment in support of developing new ARIA
features, but admit we cannot commit to helping implement or even
prototype them to prove their viability and efficacy.


>> 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.
>
> I'd say there's at least one implementation (probably two) of most ARIA 1.1
> stuff. I'm not sure about ARIA 1.2; I haven't even had a chance to look at
> it yet.

We could request a deliverable requirement of 100% testing and interop
(2+ implementations) of ARIA 1.2 features for the next version of
ARIA.

dbaron, is this thread sufficient to write-up a response? Our response
is due tomorrow (Friday 7/27) right?

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread James Teh
TL;DR: Thanks for the further explanation/clarification. I (reluctantly)
agree that these concerns make sense and have nothing else to add as far as
the response goes.

On Fri, Jul 27, 2018 at 2:33 PM, Tantek Γ‡elik 
wrote:

> > 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.
>
That's fair. I suppose there's some (now irrelevant) historical context
here: it used to be that Mozilla championed this stuff and drove others to
push accessibility forward. At present, that is not the case, and I'm
concerned it'll now be very hard to make much progress in accessibility.
Still, while that's kind of sad, I take your point that this is irrelevant
to the requirements of the charter.


> > 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.
>
Honestly, there is a lot of uncertainty at this point; I certainly couldn't
give any "formal" statement concerning what we might or might not
implement. FWIW, I believe Mozilla *should* implement this stuff, but that
all depends on me convincing leadership that we should provide more
resources for accessibility. :) Again, irrelevant to our charter response.


> 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.
>
I'd say there's at least one implementation (probably two) of most ARIA 1.1
stuff. I'm not sure about ARIA 1.2; I haven't even had a chance to look at
it yet.

Jamie
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread Tantek Γ‡elik
On Thu, Jul 26, 2018 at 8:57 PM, James Teh  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 
> wrote:
>>
>> On Thu, Jul 26, 2018 at 6:04 PM, James Teh  wrote:
>> > On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron 
>> > 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 unimpl

Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread James Teh
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 
wrote:

> On Thu, Jul 26, 2018 at 6:04 PM, James Teh  wrote:
> > On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron 
> 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


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread Tantek Γ‡elik
On Thu, Jul 26, 2018 at 6:04 PM, James Teh  wrote:
> On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron  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


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread James Teh
On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron  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.

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.

Also, the two references to a deliverable of the SVG working group
> when the SVG working group isn't currently chartered seems
> problematic.
>
Ah, yes, that does seem like a problem.

Jamie
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread Tantek Γ‡elik
On Thu, Jul 26, 2018 at 9:09 AM, L. David Baron  wrote:
> So some comments on the ARIA charter at
> https://www.w3.org/2018/03/draft-aria-charter :

tl;dr: We should show general support for work happening in this area
(per Jamie's email), however we should point out critical flaws in the
charter ("75%" etc.), formally object unless they are fixed, and add
explicit support/agreement with any other parties similarly formally
objecting.

Details inline:

> So one concern I've heard about these charters and that I probably
> share is that the ARIA charter says:
>
>   For every platform with mappings in an Accessibility API Mapping
>   specification, at least one implementation of 75% of the mappings
>   being tested on that platform will demonstrate implementability on
>   that platform. Multiple implementations of each platform are not
>   required because some platforms have only one implementation. For
>   features that are not platform-specific, passing test results in
>   at least two different implementations will be documented to
>   demonstrate implementability.
>
> This is a substantial weakening of the W3C's usual rules for
> demonstrating interoperability, and seems likely to be a bad
> precedent.

Yes and yes.

IIRC we had similar concerns about a previous Proposed Recommendation,
regarding the "at least one implementation ... on that platform", that
was accessibility related, and exiting CR without a confirmed (via
test suite) implementation for every feature. I can't seem to find it
in dev-platform however.

>  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, and

Is there some way we can ask to make this tighter (less loose)?

E.g. on platforms which only one existing implementation of previous
related spec(s)?

Like if a platform has multiple implementations already, then it is
reasonable to require 2+ implementations passing tests.

> allowing only 75% of mappings to be implemented to count as
> success seems pretty bad.

I read that as only 75% as being implementable, and 25% being
aspirational, which is not a good way to do standards, for anyone.  We
don't want specs with 25% specifiction.

We should insist that all features (including all mappings) be:
1. demonstrated to be implementable
2. pass the tests for them

If a feature is not implemented, or if it lacks tests, it should not
be able to exit CR.

We should formally object on this "75%" point.

> Also, the two references to a deliverable of the SVG working group
> when the SVG working group isn't currently chartered seems
> problematic.

Agreed, we should insist (FO) that be fixed (removed?).

> I think otherwise this seems fine.

Those were the big problems I found as well.

We should see if anyone else has filed similar criticisms and
explicitly state agreement with any that seem to agree in spirit with
the problems we see.

> On Thursday 2018-07-12 16:06 +1000, James Teh wrote:
>> I (and others in the accessibility team) think we should support these
>> charters. The ARIA working group is especially important in the future
>> evolution of web accessibility. I have some potential concerns/questions
>> regarding the personalisation semantics specifications from APA, but
>> they're more spec questions at this point and I don't think they need to be
>> raised with respect to charter. Certainly, cognitive disabilities is an
>> area that definitely needs a great deal more attention on the web, and the
>> APA are seeking to do that.
>>
>> Thanks.
>>
>> Jamie
>>
>> On Wed, Jul 11, 2018 at 3:57 PM, L. David Baron  wrote:
>>
>> > The W3C is proposing revised charters for:
>> >
>> >   Accessible Platform Architectures (APA) Working Group
>> >   https://www.w3.org/2018/03/draft-apa-charter
>> >
>> >   Accessible Rich Internet Applications (ARIA) Working Group
>> >   https://www.w3.org/2018/03/draft-aria-charter
>> >
>> >   https://lists.w3.org/Archives/Public/public-new-work/2018Jun/0003.html
>> >
>> > Mozilla has the opportunity to send comments or objections through
>> > Friday, July 27.
>> >
>> > The changes relative to the previous charters are:
>> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
>> > 2Fwww.w3.org%2F2015%2F10%2Fapa-charter&doc2=https%3A%
>> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-apa-charter
>> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
>> > 2Fwww.w3.org%2F2015%2F10%2Faria-charter&doc2=https%3A%
>> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-aria-charter
>> >
>> > Please reply to this thread if you think there's something we should
>> > say as part of this charter review, or if you think we should
>> > support or oppose it.
>> >
>> > -David

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread L. David Baron
So some comments on the ARIA charter at
https://www.w3.org/2018/03/draft-aria-charter :

So one concern I've heard about these charters and that I probably
share is that the ARIA charter says:

  For every platform with mappings in an Accessibility API Mapping
  specification, at least one implementation of 75% of the mappings
  being tested on that platform will demonstrate implementability on
  that platform. Multiple implementations of each platform are not
  required because some platforms have only one implementation. For
  features that are not platform-specific, passing test results in
  at least two different implementations will be documented to
  demonstrate implementability.

This is a substantial weakening of the W3C's usual rules for
demonstrating interoperability, and seems likely to be a bad
precedent.  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, and
allowing only 75% of mappings to be implemented to count as
success seems pretty bad.


Also, the two references to a deliverable of the SVG working group
when the SVG working group isn't currently chartered seems
problematic.


I think otherwise this seems fine.

-David

On Thursday 2018-07-12 16:06 +1000, James Teh wrote:
> I (and others in the accessibility team) think we should support these
> charters. The ARIA working group is especially important in the future
> evolution of web accessibility. I have some potential concerns/questions
> regarding the personalisation semantics specifications from APA, but
> they're more spec questions at this point and I don't think they need to be
> raised with respect to charter. Certainly, cognitive disabilities is an
> area that definitely needs a great deal more attention on the web, and the
> APA are seeking to do that.
> 
> Thanks.
> 
> Jamie
> 
> On Wed, Jul 11, 2018 at 3:57 PM, L. David Baron  wrote:
> 
> > The W3C is proposing revised charters for:
> >
> >   Accessible Platform Architectures (APA) Working Group
> >   https://www.w3.org/2018/03/draft-apa-charter
> >
> >   Accessible Rich Internet Applications (ARIA) Working Group
> >   https://www.w3.org/2018/03/draft-aria-charter
> >
> >   https://lists.w3.org/Archives/Public/public-new-work/2018Jun/0003.html
> >
> > Mozilla has the opportunity to send comments or objections through
> > Friday, July 27.
> >
> > The changes relative to the previous charters are:
> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
> > 2Fwww.w3.org%2F2015%2F10%2Fapa-charter&doc2=https%3A%
> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-apa-charter
> > https://services.w3.org/htmldiff?doc1=https%3A%2F%
> > 2Fwww.w3.org%2F2015%2F10%2Faria-charter&doc2=https%3A%
> > 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-aria-charter
> >
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review, or if you think we should
> > support or oppose it.
> >
> > -David
> >
> > --
> > π„ž   L. David Baron http://dbaron.org/   𝄂
> > 𝄒   Mozilla  https://www.mozilla.org/   𝄂
> >  Before I built a wall I'd ask to know
> >  What I was walling in or walling out,
> >  And to whom I was like to give offense.
> >- Robert Frost, Mending Wall (1914)
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> >

-- 
π„ž   L. David Baron http://dbaron.org/   𝄂
𝄒   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-11 Thread James Teh
I (and others in the accessibility team) think we should support these
charters. The ARIA working group is especially important in the future
evolution of web accessibility. I have some potential concerns/questions
regarding the personalisation semantics specifications from APA, but
they're more spec questions at this point and I don't think they need to be
raised with respect to charter. Certainly, cognitive disabilities is an
area that definitely needs a great deal more attention on the web, and the
APA are seeking to do that.

Thanks.

Jamie

On Wed, Jul 11, 2018 at 3:57 PM, L. David Baron  wrote:

> The W3C is proposing revised charters for:
>
>   Accessible Platform Architectures (APA) Working Group
>   https://www.w3.org/2018/03/draft-apa-charter
>
>   Accessible Rich Internet Applications (ARIA) Working Group
>   https://www.w3.org/2018/03/draft-aria-charter
>
>   https://lists.w3.org/Archives/Public/public-new-work/2018Jun/0003.html
>
> Mozilla has the opportunity to send comments or objections through
> Friday, July 27.
>
> The changes relative to the previous charters are:
> https://services.w3.org/htmldiff?doc1=https%3A%2F%
> 2Fwww.w3.org%2F2015%2F10%2Fapa-charter&doc2=https%3A%
> 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-apa-charter
> https://services.w3.org/htmldiff?doc1=https%3A%2F%
> 2Fwww.w3.org%2F2015%2F10%2Faria-charter&doc2=https%3A%
> 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-aria-charter
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -David
>
> --
> π„ž   L. David Baron http://dbaron.org/   𝄂
> 𝄒   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-10 Thread L. David Baron
The W3C is proposing revised charters for:

  Accessible Platform Architectures (APA) Working Group
  https://www.w3.org/2018/03/draft-apa-charter

  Accessible Rich Internet Applications (ARIA) Working Group
  https://www.w3.org/2018/03/draft-aria-charter

  https://lists.w3.org/Archives/Public/public-new-work/2018Jun/0003.html

Mozilla has the opportunity to send comments or objections through
Friday, July 27.

The changes relative to the previous charters are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2015%2F10%2Fapa-charter&doc2=https%3A%2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-apa-charter
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2015%2F10%2Faria-charter&doc2=https%3A%2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-aria-charter

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-David

-- 
π„ž   L. David Baron http://dbaron.org/   𝄂
𝄒   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform