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