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
>
>
>


-- 
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