W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: ISSUES 90, 91, 93, 96, 97 -- if you DON'T support these change proposals, support zero-change instead

From: Shelley Powers <shelley.just@gmail.com>
Date: Fri, 30 Apr 2010 10:48:05 -0500
Message-ID: <u2w643cc0271004300848p7e860846k134ff70b9d6f8352@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Sam Ruby <rubys@intertwingly.net>, HTMLWG WG <public-html@w3.org>
On Fri, Apr 30, 2010 at 10:26 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> On Fri, Apr 30, 2010 at 10:22 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Fri, Apr 30, 2010 at 8:12 AM, Shelley Powers <shelley.just@gmail.com> wrote:
>>> I was hoping to get responses such as those you've asked for.
>>>
>>> I can't believe that people dislike ALL of the change proposals,
>>> equally. I think that the fact that the co-chairs grouped these from
>>> the beginning has left them grouped, regardless of what people think
>>> about the individual items.
>>>
>>> If some have less resistance than others, then I can figure out if I
>>> need to strengthen my change proposals more, or consider dropping a
>>> couple in order to focus on the rest.
>>>
>>> With them grouped, I'm stymied as to action, because these items are
>>> not the same. They are very different constructs. I don't understand
>>> the same reasons being applied to ALL the items.
>>
>> The same reasons are not applied to all of them; I have no idea why
>> you keep asserting this.
>>
>> The counter-proposals clearly state the reasoning behind each
>> individual element, and why they're valuable.  There is then,
>> additionally, a shared section listing some reasoning that is common
>> to all the elements.
>>
>> ~TJ
>>
>
> I would have believed that more, if the counter-proposals weren't all
> lumped together.
>
> Shelley
>


And before the co-chairs get on my case for bringing up process
issues, I made that statement because I'm trying to decide if the
protests against removing these items are universally felt by all
people, or if some have stronger support than others.

The minutes for the Accessibility TF group, and even the survey for
support the group gave, demonstrate that not everyone feels equally
about all of the change proposals. I'm trying, TRYING, to get these
broken out again, to determine how to proceed with my change proposals
before the May 6th deadline.

I had hoped with the email yesterday, and today, that people would
give some indication that they feel strongly about keeping details,
but really couldn't care that much about the hidden attribute, or some
variation.

Case in point: the Accessibility TF has stated they'll fix these
items, at the same time voted to support zero-change for these items.
This is a contradiction that, to me, tells me that the TF group has
not discussed these items, individually, enough.

I can't believe that the TF agrees with keeping the hidden attribute,
considering that there's nothing in the spec that determines how this
attribute works with either the display property, or aria-hidden. In
fact, as defined, the hidden attribute is detrimental to
accessibility. It's actually detrimental, period, because it is
exactly equivalent to setting the display property to none, but
without clarity as to which property-CSS display, aria-hidden, and
hidden--has precedence if more than one is specified.

Such redundancy is not useful.

Details, aside, meter, and figure have no accessibility mapping, at
all. Details and progress have no actionable behavior defined for the
elements. There's nothing that even says what triggers details.

I can't believe that the Accessibility TF is sanguine about new
elements being introduced that are, inherently, inaccessible. I can
respect the group is busy and this is a lesser priority item. I would
think, though, if the group doesn't have the time, it should have
followed its original course, and declined to remark at all -- as they
noted in the bugs associated with these items.

Shelley
Received on Friday, 30 April 2010 15:48:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:17 UTC