Re: ISSUE-96 Change Proposal

On Thu, Apr 1, 2010 at 4:26 PM, John Foliot <jfoliot@stanford.edu> wrote:
> Shelley Powers wrote:
>>
>>
>> John, CSS is nothing more than a "bolt-on" for style. RDFa and
>> Microformats are a "bolt-on" for semantics. JavaScript is a "bolt-on"
>> for behavior, come to that.
>>
>> What you call "bolt-on" most developers call extensibility and re-
>> usability.
>
> Accessibility cannot be 'extensible' in the same way that style, enhanced
> semantics and even 'functionality' can be extensible.
>

Extensibility is a purely technical concept -- it has nothing to do
with whether something is good, or something should be required. It
just means that you can incorporate new uses without having to back to
a standards board.

Does the accessibility community really want to have to back to a
standards board in order to ensure a new innovation is accessible?

The very nature of ARIA demonstrates this. You can use it now, you
don't have to wait for new elements from HTML5. Eventually, some day
in the future, if you count on building objects into versions of HTML,
HTML will be a wall, not a door.

>  * Accessibility advocates still suggest that for 'mission critical'
> functionality, server-side scripting is better than client side (and the
> popularity of PHP confirms this in many ways); yes, go ahead and use JS if
> you can, but be prepared for the graceful degradation that you will likely
> experience in some cases.
>

Not sure the point you're making here.

>  * Separating style from content aids accessibility, as it gives control
> to the end user to modify aspects of the design to address specific
> requirements/needs. (I wish it were easer across the board to load custom
> client style sheets: it can be done but it is complex right now...)
>

It's also kind of handy for other uses, too.

>  * Native semantics can be enhanced with RDFa and Microformats/Microdata,
> but the native semantic construct is always the baseline: <div + attribute
> of your choosing> can be styled, scripted and enhanced with semantic
> additions, but it still lacks any core meaning - it will remain a
> meaningless div first and foremost.
>


If a div element is annotated with RDFa and ARIA, which provide
information about its purpose, why is it less semantic than something
like article, or section?

Come to that, what is meaningful about a figure element that allows
the same content as a div? Or an aside element that no one knows for
sure how to use, or why to use? In particular an aside, as sidebar,
has "meaning" in print, but no meaning at all in the web page. So, why
does it exist? How is the world of the web improved by having it?

Semantics are dependent on a lot more than using an article element
over a div element.


> Accessibility must be foundational, not extensible, in this regard. The
> fact that ARIA seeks to 'extend' accessibility to elements and scripted
> actions is actually not optimal, but is necessary today, as the original
> HTML didn't account for these things. Moving forward, we *should* account
> for as many as we can.
>

To note again, extensibility is a technical concept. it doesn't mean
optional, or unimportant. It's just a way of being able to incorporate
new functionality without having to wait on a standards group. Or have
to wait on a browser or other user agent, if they support the
extensibility.

Puts the control back in the hands of designers, developers, and
users, rather than the powers-that-be that fuel the HTML WG.

>
>>
>> But it will never be built in. You all seem to assume that really,
>> there's only 20 or 30 built-in behaviors and once we have these, the
>> job is done.
>>
>> This will never happen. The web is synonymous with innovation.
>
> Right. And adding new, extensible <elements> contributes to and reflects
> that innovation... or are you suggesting that we just dumb down to <div>
> and then pile on the extensions? That seems counter-productive to me, and
> limiting: an attribute cannot take on a child attribute can it?
>

I think you're misunderstanding extensibility. Codifying elements in
the HTML5 specification is not extensibility in action. The use of
ARIA is, as is RDFa.

>
>>
>> You know it's odd, but in all of the ARIA stuff I've read online,
>> tutorials, articles, and specs, I've never read anyone who wrote,
>> "This stuff is fun!"
>
> Because, honestly, it really isn't.  It's important, but not fun, and
> that's the rub right there. So if we can create elements that don't
> require additional massaging to make accessible, that's a huge win,
> because it *is* fun to create something new; it *is* fun to add slickeroo
> styling to it; it *is* fun to add extended semantics using microformats,
> etc.; but it's not fun doing stuff that the average author cannot tangibly
> appreciate directly, because they don't need to use AT daily. The single
> largest failure w.r.t. accessibility is that currently the only way to get
> huge chunks of your code accessible is to do additional work - the current
> 'native' code does not provide it. Surely we can innovate and do better
> than that; semantically appropriate elements extends the extensibility
> even further.
>

But it can be fun, too. We can do the right thing, and have fun, too.

I giggled like a mad woman when I added ARIA to an example for my
book, and it actually worked with NVDA. I called my roommate in to
show him. I had a blast. Was that somehow wrong?

When I wrote about it in my book, I wrote about how much fun I had
working with the ARIA states and roles, and especially live regions.
Was that somehow wrong? Not striking a serious enough tone?


>
>>
>> When you coach things as a "serious duty", don't be surprised if the
>> reaction is equivalent to telling a 6 year old to eat his broccoli,
>> because it's good for him.
>>
>> You can ask Kathy Sierra and Molly if I'm right on this.
>
> I know Molly quite well, and I've done my fair share of stand up and
> dog-and-pony shows in my time. Trust me, I know how to actually 'sell'
> this stuff myself, been doing it for over a decade.  Right now, your
> suggestion is to continue to tell authors to eat their broccoli (here: use
> ARIA), while the newer proposals are closer to "...we'll hide the veggies
> in a fruit drink[1], or blend it into the pizza sauce[2]...", fruit drinks
> and pizza being *way more fun* than broccoli...
>

Actually, no, I'm saying we should tell developers a) how simple it
is, b) that it works, and c) that it can be fun to do the right thing.

Ten years ago, five years ago, even a couple of years ago, we did not
have this capability. We developers were frustrated because we were
told to create accessible applications, but we didn't have the tools.
Now we have the tools.

Now, keyboard stuff is tricky. I like how HTML5 has cleared up what
happens with tabindex. Now that is the kind of think I did expect with
HTML5 -- minor modifications, cleanup, and clarification.

>>
>> Appreciated. I hope I don't seem overly aggressive. I should stop,
>> pull back, and take this up on my weblog.
>>
>
> No worries, it's a worthwhile discussion.
>
> JF
>

Shelley

> [1 http://en.wikipedia.org/wiki/V8_(beverage)#V8_Fruit_.26_Vegetable_Juice
> ]
> [2 http://www.ehow.com/how_2204294_sneak-vegetables-pizza.html]
>

Received on Thursday, 1 April 2010 23:09:23 UTC