Re: Thoughts towards an accessible <canvas>

I wholeheartedly agree with your concept and overall position,

However I am not so sure about your idea of not rendering non-conforming
content

"Finally, I propose that any instance of <canvas> that lacks at a minimum
the 2 proposed mandatory values be non-conformant and not render on screen."

Would you apply the same rules all non-text content such as images?

The crucial thing is that the users software (browser, screen reader, etc.)
is able to render the appropriate alternative (if it exists). And for this
to happen you are right that the software developers as well as web authors
need to be given a definitive, unambigous, set of guidelines. But I don't
think you can ask Microsoft etc to create browser that refuse to display any
content that is not fully accessible.

Richard

----- Original Message ----- 
From: "John Foliot - WATS.ca" <foliot@wats.ca>
To: "Wai-Ig" <w3c-wai-ig@w3.org>; <wai-xtech@w3.org>; "'HTMLWG'"
<public-html@w3.org>
Cc: "WebAIM Discussion List" <webaim-forum@list.webaim.org>; "Gawds_Discuss"
<gawds_discuss@yahoogroups.com>
Sent: Tuesday, March 17, 2009 7:00 AM
Subject: Thoughts towards an accessible <canvas>


> Requirement:
> When authors use the canvas element, they must also provide content
> that, when presented to the user, conveys essentially the same function or
> purpose as the bitmap canvas. This content may be placed as content of the
> canvas element. The contents of the canvas element, if any, are the
> element's fallback content.
> [source: http://dev.w3.org/html5/spec/Overview.html#the-canvas-element]
>
> But what, exactly, should content authors include as their fallback
content?
>
> This has been an on-going problem since the introduction the <noframes>
and
> <noscript> elements, officially released as part of the HTML4
specification
> almost a decade ago. Recollections of "This site uses frames, so get a
> browser that doesn't suck" are likely in everyone's memory (at least, of
> those likely to be reading this) and it highlights a basic problem: there
is
> no standard for applying and conveying this alternative, or 'fallback'
> content, and so authors are left trying to guess what to do. Earlier this
> year, I complained that the HTML5 Draft specification made including this
> content optional, using the word 'should' (in the RFC 2119 way) instead of
> 'must'. The current draft has apparently corrected this deficiency as it
now
> states 'must' - however what is missing is instruction (mandate?) on what
> this fallback content should be.
>
> An oft stated goal of the HTML5 WG is that they do not want to over-burden
> content authors' work-flow by adding extra steps; that most authors will
not
> bother and it makes things overly complicated. I understand and accept
that.
> Yet to ensure that we reach even a modicum of equivalency we need to
ensure
> that some basic information be provided to all users. And if we learned
one
> thing from HTML 4's @accesskey debacle, it's that consistency is crucial.
>
> With these thoughts in mind then, how can we ensure that the canvas
element
> is at the very least user-friendly to those who may never actually be able
> to consume the author envisioned content of <canvas>? I propose a 'block'
of
> 5 attributes - 2 mandatory and 3 optional - that constitutes the fallback.
> This block, essentially meta-data, would be contained in-line, perhaps as
a
> definition list (with an ARIA @role?), or through some other means (could
we
> use the <meta> element here?) - the main point being that a prescribed,
> mandated means should exist to convey this data, so that all instances of
> <canvas> would consistently include these values. Finally, I propose that
> any instance of <canvas> that lacks at a minimum the 2 proposed mandatory
> values be non-conformant and not render on screen. The inclusion of this
> information should not be left to chance - the specification requires that
> some fallback content exist - and if it does not exist then the <canvas>
> element is incomplete, thus it should simply fail all users, not just
those
> who cannot access the content as does the mainstream. As the values are
> pre-determined by the specification, their presence can be
programmatically
> verified and the 2 mandatory attributes are so basic in nature that it is
> unlikely that they will be 'gamed' or misused/abused. Finally, due to the
> 'consistency' factor, authoring tools could be programmed to collect and
> insert this data with little overhead or intrusion to the content author.
>
> The proposed attributes are:
>
> Title:
> [mandatory] A brief description or name of the canvas content. Think
> along the lines of @alt - tell the user of a user-agent that does not
> support canvas what is in this region: its purpose or function. This is
not
> to be verbose!
> Examples:
> * Dynamic chart of this week's votes from American Idol
> * A 3-dimensional shooter game
> * Bespin - A dynamic on-screen editing tool
>
> Author:
> [mandatory] The owner or creator of the widget. May be an individual
> or entity, and may also include the anchor element to another URI
> Examples:
> * <a href=http://www.fox.com>The FOX Broadcasting Company </a>
> * Joe Blough for My Web Developer Company LLC
> * Mozilla Labs Project - Dion Almaer, on behalf of the Bespin
> development team
>
> Description:
> [optional] A more detailed explanation, expanding upon the Title. We
> cannot presume that all users want a verbose explanation of the canvas
> 'widget', however there are times when some might, and providing this
> information would be of great use.
> Examples:
> * "The FOX Broadcasting Company's popular American Idol television
> program allows viewers to vote on their favorite performer each week. This
> on-screen application creates a visual representation of the weekly votes
> cast using a common bar graph, with updates posted every 60 seconds."
> * "A small, on-screen game with a one-person shooter character who
> must navigate a maze while also shooting opponents. The goal or the game
is
> to exit the maze while also shooting all of the characters. Players can
also
> attempt to beat their score by completing the game in increasingly shorter
> time intervals."
> * "Bespin is a Mozilla Labs experiment that proposes an open,
> extensible web-based framework for code editing that aims to increase
> developer productivity, enable compelling user experiences, and promote
the
> use of open standards."
>
> Alternate:
> [optional] Borrowing from the idea of @longdesc, this would be an
> URI that points to an alternative rendering of the content/concept that
the
> canvas region is delivering. For example, in the case of the dynamic
> bar-graph, the data driving the bar-graph could also be represented in a
> tabular (<table>) format. The canvas 'widget' might also be available as a
> stand-alone download in which case the URI for the download would be
> provided here, or it might be nothing more than a 'screen-capture' image
> (with appropriate @alt)
>
> Notes:
> [optional] A catch all attribute which would be open for use to the
> content developer to use as desired. The content of Notes would be text
> only, and might include items such as change-log data or version number,
or
> other developer commentary as required.
>
> It is important to state that this is just an opening proposal - it should
> be discussed, analyzed, dissected and ruminated upon. It is my belief
> however that we cannot and should not leave any of this to chance, and
> equally, we cannot expect content authors to know what we mean when we
talk
> about 'fallback content'. We need to state clearly and unequivocally what
we
> mean by this, and provide them with the template of these requirements to
> ensure they get it right the first time, and every time. The specification
> currently already says they 'must' add fallback content, now we need to
> define what that content should look like.
>
> JF
>
>
>

Received on Wednesday, 18 March 2009 01:20:35 UTC