Re: Removal of other semantic elements

On Sun, Apr 4, 2010 at 5:56 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Apr 4, 2010, at 2:27 PM, Shelley Powers wrote:
>
>
> My change proposals primarily responded from an accessibility
> perspective because that's how the HTML5 editor styled his rationales
> for rejection--based purely on accessibility. I demonstrated that the
> elements in question aren't _necessary_ for accessibility, because
> ARIA provides an alternative. My demonstration basically refuted his
> rationale that these elements were _essential_ to accessibility in
> HTML5.
>
> In fairness to everyone's arguments, I don't think anyone claimed that new
> elements are essential to accessibility, merely that having them is an
> accessibility improvement relative to not having them.
>

When I read the following rationale for keeping hidden:

"Rationale: hidden="" is a key part of HTML5's accessibility story and
represents one of the main accessibility improvements over HTML4 for dynamic
applications."

Or for keeping details:

"The <details> element is needed to provide an accessible way of reflecting a
common application widget in HTML-based applications without requiring authors
to use extensive scripting, ARIA, and platform-specific CSS to get the same
effect."


Though the word "essential" isn't used, there is a stress on how
important this is for accessibility. The same applied to progress,
though, admitted, less so the other rejections. I demonstrated that
neither is essential for accessibility, and then that seems to have
triggered the current discussions.

> Would it help if I edited the change proposal to put more of the
> emphasis on custom UI libraries as compared to native elements?
>
> You're welcome to adjust your Change Proposals any way you like to make them
> more persuasive.
> If you make a change along the lines described above you may want to
> consider:
> (a) Is native element vs. a UI library really an either-or choice? Why is it
> bad to have both?
> (b) What if native elements were a useful building block for UI libraries
> (for example by providing a high degree of visual customization through CSS,
> like <input type=text> and <input type=button> do in most browsers)?
>
> It would help if I had arguments specific to custom UI libraries
> versus native elements other than the ones that Ian provided, because
> I'm having to guess what these are. Would it be better to wait until
> counter-proposals and then edit my proposals accordingly?
>
> I don't think you need to worry about refuting future arguments - just make
> a case for why removing the elements and attributes in question from HTML5
> is on balance an improvement. Your goal should be to actively make the case
> for your proposal, not simply to respond to opposing arguments.
>
> I don't want to waste the group's time, but I'm not sure that all of
> the arguments I've given in my proposals have been given due
> consideration, because of the "ARIA versus native element" tangent.
> Which I apologize for aiding and abetting.
>
> If there are other arguments from your rationales that you'd like to
> highlight, I think it would be good to bring those up on the discussion
> thread.

Unless the co-chairs see a problem with my specs now, I would rather
wait for counter-proposals so I can respond to these, as well as make
any other edits.

So I guess we wait until the calls for counter-proposals.

> Regards,
> Maciej
>

Thanks

Shelley

Received on Sunday, 4 April 2010 23:06:34 UTC