RE: Canvas and ARIA alternatives

Cheers Benjamin, interesting article and I wouldn't disagree with it's
conclusion. It also sounds like we both feel the same way regarding how we
would prefer to see this particular requirement satisfied but perhaps feel
differently about what is realistically achieveable and how this could be
achieved.

>From your email:

>First, W3C has little influence with which to encourage or discourage
content developers.

I understand this and wouldn't argue with this point in general. However,
with regard to accessibility as mentioned previously, I feel there is a real
opportunity to at least try to affect some change through WCAG. Whether the
time is right to look at this is open to debate. And whether in reality it
would have much affect is also uncertain. But to simply dismiss any notion
of being able to influence for example the use of the canvas element instead
of the accessible alternatives for user input because "the W3C have little
influence with which to encourage or discourage content developers" seems a
little defetest. Indeed if one applied this reasoning more broadly, what is
the point in WCAG? 

>From the article:


"Most of the successful versions of HTML have been "retro-specs," catching
up to the world while simultaneously trying to nudge it in the right
direction."

My point is that the canvas is already out there, as are many other
technologies which we cannot and indeed should not attempt to change. But I
feel we could be doing a little more nudging as mentioned above.

>Third, W3C has little influence over the feature development agenda.
When W3C blocks interoperability by failing to work on specs that have
market interest, the internet routes around that damage and the specs get
written elsewhere. For example, when W3C was hopelessly pushing XHTML2, the
community went to WHATWG and continued work on HTML. W3C has a tiny staff
and specs, tests, and implementations are all mostly developed on by (a
still insufficient number of) people outside by the W3C, who tend to work on
features of interest to them or their employers. 

I'm absolutely not suggesting that we should try and do anything like this.
I do feel it is very important to discuss how best to deal with this kind of
situation  though. The language and approach adopted is so important when
seeking to effect change and I'm sure the experience gained by the W3C from
the past will be helpful in such situations.  

I would also add that times have changed and while I wouldn't necessarily
disagree that shipping code wins, I feel it is a little more complicated
than this now. The organisations big enough to adopt this kind of approach
and make a difference are largely sensitive to moral, ethical, social and
inclusive agendas. While this in itself isn't going to change the world in
terms of accessibility, it does influence decisions and over time the
potential commercial benefits of ensuring their products and services are
available to the widest possible audience. It's already happening where
organisations are looking to sell their products to governments for example
.

Cheers
Ian

    



 the 









   

-----Original Message-----
From: Benjamin Hawkes-Lewis [mailto:bhawkeslewis@googlemail.com] 
Sent: 08 August 2012 08:24
To: Ian Sharpe
Cc: duboisp2@gmail.com; WAI Interest Group
Subject: Re: Canvas and ARIA alternatives

On Tue, Aug 7, 2012 at 11:03 PM, Ian Sharpe <isforums@manx.net> wrote:
> 1. At a glance, I suspect the kind of styling available via this 
> particular library is probably achieveable using CSS3, such as gradient
backgrounds.

Some of the stylings yes, some of the stylings no. The library provides a
common API and uses a common implementation in both situations.

> 2. If there is such demand for more fine-grained control over the 
> appearance of standard elements, not currently available through CSS, 
> surely it would be more sensible to extend what is possible through 
> CSS to achieve this? I can already hear some saying that CSS would 
> become even more bloated and there will always be something that 
> somebody wants to be able to do that would be too complex to 
> implement. But what is worse, encouraging people to abuse elements to 
> address a perceived shortfall in existing standards and then having to 
> spend significant time and resources trying to work out how to deal 
> with the fallout from an accessibility perspective? Or extending CSS 
> to provide more control and flexibility in appearance using a well
understood and accessible presentation model?

"Shipping code wins".

http://diveintohtml5.info/past.html

First, W3C has little influence with which to encourage or discourage
content developers.

Second, there's no value in working on existing _standards_, as opposed to
working on existing features actually in use. Whether something is
"standard" or not has little impact on the web corpus.
Witness the sad history of the <embed> and <object> elements.

Third, W3C has little influence over the feature development agenda.
When W3C blocks interoperability by failing to work on specs that have
market interest, the internet routes around that damage and the specs get
written elsewhere. For example, when W3C was hopelessly pushing XHTML2, the
community went to WHATWG and continued work on HTML. W3C has a tiny staff
and specs, tests, and implementations are all mostly developed on by (a
still insufficient number of) people outside by the W3C, who tend to work on
features of interest to them or their employers.

> Or to think about it in a different way, if you take this approach to 
> the extreme, there's no reason why the entire web couldn't end up 
> using the canvas as the primary user interface. Kind of a world away 
> from the semantic web.

Indeed, that could happen.

I happen to prefer the traditional layering of style and behavior on top of
semantic markup over the <canvas> approach, I would like to see the
traditional layering enhanced with new features to enable wider
customisation of look and feel. This is actually a not uncommon preference
in the community working on these specs. For example, the WHATWG HTML editor
Ian Hickson has long been vocal about improving contenteditable rather than
adding features for trying to building purportedly accessible rich text
editors in canvas.

However, actually providing such features is hard. That's partly because
with <canvas> backings, you can leave the visual rendering to content
developers rather than defining a new rendering feature and precisely how it
interacts with all the other rendering features. This complexity is an
important reason why progress on specifying CSS is so very slow.

The idea that we can do it all by extending CSS is proving naive because
user agent implementations of native controls are often very different to
reflect platform norms. The feature development community has already had
one go at defining features for writing custom widgets
(XBL2) and it tanked. People are now working on web components, maybe that
will prove more effective in the market.

Anyway, there's little progress on CSS form styling capabilities. If someone
wants this, they need to step up and work on implementations, tests, and
specs.

--
Benjamin Hawkes-Lewis

Received on Wednesday, 8 August 2012 11:47:09 UTC