RE: Canvas and ARIA alternatives

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

Received on Tuesday, 7 August 2012 22:03:33 UTC