RE: Canvas and ARIA alternatives

Cheers Steve, fair enough. I'll take a look at the references you site when
I get the chance. 
 
I assume that such decisions are not irreversable though in the light of any
compelling argument to the contrary? I'm certainly not suggesting that this
is the situation here by the way and given that I seem to be the only one
making the point, it almost certainly is not. But I would be interested to
know none the less. And where would be the best place to raise such an
argument if not here?   
 
I assume then that this would also explain why there would be no desire to
attempt to discourage the use of such techniques through WCAG? It would seem
silly if one part of an organisation was attempting to build a house while
another part was attempting to knock it down.
 
This doesn't feel right to me though. I guess it just depends on which way
you approach the "problem" re accessibility and how to deal with it. 
 
I get the impression that the W3C have taken the view that it's better to be
involved and respond positively to try and address issues around
accessibility as and when they arise. While I have a great deal of sympathy
with this approach and totally understand the benefits and reason for
adopting it, surely at some point we need to draw a line? I would be very
interested to know where the W3C draw this line?   
 
That's not to say that things haven't improved over the past 10 years or so
by the way, largely as a result of this approach I'm sure. But at the same
time, we have seen the introduction of new approaches which have moved the
bar further away again, just when it was starting to get within reach. I
understand that you can't stop progress and as mentioned previously, I'm
absolutely not suggesting anyone should, and we need to be involved in
trying to ensure that new technologies facilitate accessibility. 
 
But I do feel it would be helpful to look at whether this approach in itself
is actually having the desired result on accessibility from the user's
perspective. Because from where I'm sitting, that's not the case and feel
that there are now other ways to effect change worthy of consideration, in
addition to what is already happening behind the scenes.
 
I'm not saying it's easy or that there is even a solution to the problem,
but I feel something needs to change if we are ever going to see a truely
inclusive web.
 
Cheers
Ian
 
 
 
 
 
 
 
  _____  

From: Steve Faulkner [mailto:faulkner.steve@gmail.com] 
Sent: 08 August 2012 12:59
To: Ian Sharpe
Cc: WAI Interest Group
Subject: Re: Canvas and ARIA alternatives


Hi Ian, 
yes I figured that, but the W3C HTML accessibility taskforce thinks
otherwise as use cases [2] have been provided by various stakeholders for
the need to provide methods to make canvas content accessible.

There has been a lot of discussion on the topic over a number of years [1].


[1]
http://www.w3.org/WAI/PF/HTML/wiki/Canvas
http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals
http://lists.w3.org/Archives/Public/public-canvas-api/

[2]
http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Accessibility_Use_Cases
http://wiki.whatwg.org/wiki/Canvas

regards
SteveF


On 8 August 2012 12:49, Ian Sharpe <isforums@manx.net> wrote:



Hi Steve
 
Apologies for any confusion but my point was that I personally don't feel we
should be spending time and resources encouraging the adoption of such
appraoches when perfectly reasonable accessible alternatives exist.
 
Cheers
Ian
 

  _____  


From: Steve Faulkner [mailto:faulkner.steve@gmail.com] 

Sent: 08 August 2012 03:27
To: Ian Sharpe 

Cc: WAI Interest Group
Subject: Re: Canvas and ARIA alternatives


Hi Ian,  

thanks for the pointer to the canvas control library.
we [1] are always looking for examples of the differing uses of canvas to
help inform the requirements for canvas accessibility in HTML5

[1] http://www.w3.org/WAI/PF/html-task-force

regards

SteveF


On 7 August 2012 23:03, Ian Sharpe <isforums@manx.net> wrote:


By sheer coincidence I've just come across the article below which would
seem to demonstrate the point I was making. It is the beginnings of a canvas
control library, and I'm sure there are others if I looked.

I haven't looked at the article in detail or tried the code yet but based on
what I did read I would make the following points:

1. At a glance, I suspect the kind of styling available via this particular
library is probably achieveable using CSS3, such as gradient backgrounds.

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?

I suspect that in most cases, CSS would be sufficient to address most
people's requirements and if it isn't, it could (should) be extended to do
so.

I do accept the points others have made regarding valid use case scenarios
but I really feel this kind of approach should be more actively discouraged.
How this might be achieved though is obviously open to debate.

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.

Anyway, here's the article:

http://www.codeproject.com/Articles/410856/Canvas-Control-Library


Cheers
Ian








-----Original Message-----
From: Pierre Dubois [mailto:duboisp2@gmail.com]
Sent: 06 August 2012 19:18
To: Benjamin Hawkes-Lewis
Cc: WAI Interest Group
Subject: Re: Canvas and ARIA alternatives

Thanks Benjamin,

Now I better understand the purpose of the aria-describedby attribute.

I updated the charts widget as per your recommendation and now the
aria-describedby is only used if the table has a description in his caption
element.

> The table should is available in a visible form, e.g. for users who
> have difficulty understanding the chart and for users who want to
> extract the data. (Could also leave it fully visible or hide it
> off-page behind a link.)

FYI - It is possible for the Web Editor that would use this widget to do not
get the table encapsulated in a details/summary. They would just need to add
the css class 'wb-charts-noencapsulation-true' in the table class attribute.

Cheers,

:-)

Pierre Dubois
819-773-2881

~ Envoyez de mon telephone

-----Original Message-----
From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Sun, 5 Aug 2012 11:01:47
To: Pierre Dubois<duboisp2@gmail.com>
Cc: Ian Sharpe<isforums@manx.net>; <rcorominas@technosite.es>; WAI Interest
Group<w3c-wai-ig@w3.org>
Subject: Re: Canvas and ARIA alternatives

On Sat, Aug 4, 2012 at 5:47 AM, Pierre Dubois <duboisp2@gmail.com> wrote:
> Once the graphic are generated, I decided to auto set the attribute
> aria-describedby on the figure element to provide a better accessibility.
> The aria-describedby attribute have a reference to the HTML table.
> Do you think that is a sufficient technique to set the accessibility
> for the Canva / SVG element in my case ?

Yeah, I think ARIA has generated a lot of confusion over usage of
aria-describedby.

UAs are required to reduce the referent of aria-describedby (your
table) to a plain text string for exposure as an "accessible description"
for the canvas.

http://www.w3.org/WAI.new/PF/aria/roles#namecalculation

That some UAs might additionally expose a mechanism for navigating to the
accessible description doesn't mean you can safely refer to content that
cannot be easily consumed when its structure and semantics are stripped away
to plain text. Basically aria-describedby is only suitable for short
descriptions. Unfortunately ARIA provides no mechanism for separating out
what contributes to the accessible description and the navigational link.
There's been a bit of discussion around adding an @aria-describedat
attribute, reusing @longdesc, or minting a new HTML attribute for this
purpose.

So I don't think your technique is ideal.

For now, I think you're better off just making reference to the long text
alternative via the short text alternative, like so:

  <figure>
    <figcaption>
       <strong>2011 Sales</strong>
       <p id="desc">Sales grew from $595,304 per month to $847,390.</p>
    </figcaption>
    <svg role="img" aria-label="2011 Sales Chart. Details in table
following." aria-describedby="desc"></svg>
    <details>
       <summary>2011 Sales Table</summary>
       <details>
          <table aria-label="2011 Sales Table"
aria-describedby="desc">...</table>
       </details>
  </figure>

A short visible summary is included of what the chart actually tells us -
more digestible than either chart or table, potentially. It is explicitly
designated as the short accessible description for both canvas and table.
<strong> is used to distinguish the reference title of the figure from the
rest of the caption.

The short text alternative for the <svg> element makes reference to the long
text alternative that follows, for the aid of users with visual impairments
jumping between images on the page; compare this
technique:

http://www.w3.org/TR/WCAG20-TECHS/G74.html

In theory <svg> has its own accessibility semantics (e.g. the <description>
element), but as these are poorly supported I've overridden them at the ARIA
level using role="img", with aria-label and aria-describedby to provide text
alternatives.

The table should is available in a visible form, e.g. for users who have
difficulty understanding the chart and for users who want to extract the
data. (Could also leave it fully visible or hide it off-page behind a link.)

--
Benjamin Hawkes-Lewis







-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar -
www.paciellogroup.com/resources/wat-ie-about.html
<http://www.paciellogroup.com/resources/wat-ie-about.html> 






-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar -
www.paciellogroup.com/resources/wat-ie-about.html
<http://www.paciellogroup.com/resources/wat-ie-about.html>