[agenda] BPWG Teleconference 2009-11-03

[Jo Rabin-2]

Hello everyone, service continues this week now that North America and
Europe have resumed their customary time difference.

Yet again a short call in prospect as we wait for those last call
comments to arrive.

When that I was and a little tiny boy
With hey, ho, the wind and the rain,
A foolish thing was but a toy,
For the rain it raineth every day.

[Except in Trinidad, I expect]

Attendance is open to W3C Members Only

Chair: Jo

Team Contact: Francois

Known Regrets: Sangwhan, Kai, Sean, Bruce

Please make sure that if you are sending regrets you do so _before_ the
call and please use the member list to do so:

mailto:member-bpwg@...?subject=Regrets%20for%20BPWG%202009-11-03

Agenda:

1. Admin

London F2F update on registration ... if you have not done so please
indicate your intentions either way [1]

[1] http://www.w3.org/2002/09/wbs/37584/f2f-london-2009/

The "Extended Guidelines" Note [2] was published on Tuesday 20th Oct.

[2] http://www.w3.org/TR/2009/NOTE-mwbp-guidelines-20091020/

The CT Landscape Note [3] was published on Tuesday 27th Oct.

[3] http://www.w3.org/TR/2009/NOTE-ct-landscape-20091027/

2. Update on MWABP (BP 2)

Review of any Comments received.

Update from Adam on Editorial Revision.

Review of any comments (none so far, afaik)

3. Update on CT

Review of dialogue between Eduardo and Francois on Eduardo's LCC
regarding "non traditional browsing applications" - see thread starting
at [4].

[4]
http://lists.w3.org/Archives/Public/public-bpwg-comments/2009OctDec/0034.html

Contributions of tests for the CT Test Suite.

5. AOB

Review of and tidy up of ISSUEs and ACTIONs - we have no open ISSUEs and
we have a handful of open actions on DKA, JeffS and Adam (hint hint).

Logistics:

Date: 2009-11-03T1430Z
[0630 US Pacific, 0930 US Eastern, 1430 UK/Ireland, 1530 CET, 1630
Helsinki]

Phone: tel:[phone], tel:[phone] or tel:[phone]
Code 2794 ("BPWG") followed by #

IRC: irc://irc.w3.org:6665#bpwg

[Jeff Sonstein-2]

On Nov 3, 2009, at 6:12 AM, Jo Rabin wrote:

> 5. AOB
>
> Review of and tidy up of ISSUEs and ACTIONs - we have no open ISSUEs  
> and we have a handful of open actions on DKA, JeffS and Adam (hint  
> hint).

RE: ACTION-885

I thought we had finished w this & closed it...
last I remember
the text now in the document
(courtesy the hacking-and-slashing
  ummm
  I mean "fine editing"
  of Adam <grin/>)
was something everyone could at least "live with"

while I would *like* to be providing more detailed guidance to  
developers
nonetheless
I can *live with* just saying what is in the document at this point:

-----  snip  -----
3.5.10.1 What it means

Canvas and SVG provide alternative options for incorporating graphics  
in a Web application. Support for these technologies varies across  
devices so in many cases the choice of which technology to use will  
depend on the target devices for a given application.

The Canvas element defines a drawable bitmap region onto which  
JavaScript can be used to render simple graphic primatives. In  
contrast, SVG is an XML language for defining vector graphics -- the  
nodes and elements are added to a DOM and can be modified later using  
JavaScript.
SVG is well-suited for graphics that must be scalable and whose  
components need to be modified (e.g. panning and zooming a map)  
whereas Canvas is best suited for cases where a static bitmap is  
sufficient (e.g. drawing a scatter-chart, visual effects, reflections  
etc).

In most cases Canvas is faster and should be preferred if it meets  
requirements. However, since Canvas generates a flat bitmap it is not  
inherently accessible and so should not be used as the sole means of  
conveying information.
-----  snip  -----

my only teenie quibble
would be with the last sentence
which I think might better be changed from:

"it is not inherently accessible and so"

to instead read:

"it is inherently not accessible as it is not part of the DOM, and so"

can we close this out at this mtg?

jeffs

--
"Workers were called,
   and human beings came."
- Max Frisch -
============

Prof. Jeff Sonstein

http://www.it.rit.edu/~jxs/
http://ariadne.iz.net/~jeffs/
http://chw.rit.edu/blog/
http://ariadne.iz.net/~jeffs/jeffs.asc
http://www.it.rit.edu/~jxs/emailDisclaimer.html

[Adam Connors]

This looks reasonable to me, I'll add your text change to the outstanding list of editorial changes which I expect to get to this week.

Thanks,

Adam.

On Tue, Nov 3, 2009 at 10:45 AM, Jeff Sonstein <jxsast@...> wrote:

On Nov 3, 2009, at 6:12 AM, Jo Rabin wrote:

5. AOB

Review of and tidy up of ISSUEs and ACTIONs - we have no open ISSUEs and we have a handful of open actions on DKA, JeffS and Adam (hint hint).

RE: ACTION-885

I thought we had finished w this & closed it...
last I remember
the text now in the document
(courtesy the hacking-and-slashing
 ummm
 I mean "fine editing"
 of Adam <grin/>)
was something everyone could at least "live with"

while I would *like* to be providing more detailed guidance to developers
nonetheless
I can *live with* just saying what is in the document at this point:

-----  snip  -----
3.5.10.1 What it means

Canvas and SVG provide alternative options for incorporating graphics in a Web application. Support for these technologies varies across devices so in many cases the choice of which technology to use will depend on the target devices for a given application.

The Canvas element defines a drawable bitmap region onto which JavaScript can be used to render simple graphic primatives. In contrast, SVG is an XML language for defining vector graphics -- the nodes and elements are added to a DOM and can be modified later using JavaScript.
SVG is well-suited for graphics that must be scalable and whose components need to be modified (e.g. panning and zooming a map) whereas Canvas is best suited for cases where a static bitmap is sufficient (e.g. drawing a scatter-chart, visual effects, reflections etc).

In most cases Canvas is faster and should be preferred if it meets requirements. However, since Canvas generates a flat bitmap it is not inherently accessible and so should not be used as the sole means of conveying information.
-----  snip  -----

my only teenie quibble
would be with the last sentence
which I think might better be changed from:

"it is not inherently accessible and so"

to instead read:

"it is inherently not accessible as it is not part of the DOM, and so"

can we close this out at this mtg?

jeffs

--
"Workers were called,
 and human beings came."
- Max Frisch -
============

Prof. Jeff Sonstein

http://www.it.rit.edu/~jxs/
http://ariadne.iz.net/~jeffs/
http://chw.rit.edu/blog/
http://ariadne.iz.net/~jeffs/jeffs.asc
http://www.it.rit.edu/~jxs/emailDisclaimer.html

[Jeff Sonstein-2]

On Nov 3, 2009, at 11:10 AM, Adam Connors wrote:

> This looks reasonable to me, I'll add your text change to the  
> outstanding list of editorial changes which I expect to get to this  
> week.

thank you
jeffs

--
"It's not that I am so smart,
  it's just that I stay with problems longer."
- Albert Einstein -
============

Prof. Jeff Sonstein

http://www.it.rit.edu/~jxs/
http://ariadne.iz.net/~jeffs/
http://chw.rit.edu/blog/
http://ariadne.iz.net/~jeffs/jeffs.asc
http://www.it.rit.edu/~jxs/emailDisclaimer.html

[Alan Chuter]

The document says "Canvas ... is not inherently accessible and so should
not be used as the sole means of conveying information." [1]

Perhaps the word "alternative" is needed here, "If you need to use
canvas, then provide an alternative."

I think that as this is about dynamic graphics the document should also
add the proviso that the alternative should be updated as the image is
redrawn, if that changes its meaning. How this is done in canvas I don't
know, probably by the same script that updates the image. Updates to the
DOM (which would be used for the alternative) are detected by some
current mobile screen readers. This also applies to SVG. SVG supports
accessibility but in practice it requires a text alternative for the
whole image.

Another solution might be to require that it be used in an
accessibility-supported way, as defined by WCAG [2].

[1] http://www.w3.org/TR/mwabp/#bp-canvas
[2] http://www.w3.org/TR/WCAG20/#accessibility-supporteddef

--
Alan Chuter
Departamento de Usabilidad y Accesibilidad
Consultor
Technosite - Grupo Fundosa
Fundación ONCE
Tfno.: 91 121 03 30
Fax: [phone]
achuter@...
http://www.technosite.es

[Jeff Sonstein-2]

some good points

On Nov 3, 2009, at 12:17 PM, Alan Chuter wrote:

> Perhaps the word "alternative" is needed here, "If you need to use  
> canvas, then provide an alternative."

I am not sure what that alternative might be...

> updated as the image is redrawn, if that changes its meaning. How  
> this is done in canvas I don't know,
> probably by the same script that updates the image.

I am not sure I can see any other way to accomplish this than through  
scripting

> Another solution might be to require that it be used in an  
> accessibility-supported way, as defined by WCAG [2].

I am also not sure how to make a canvas object meaningfully accessible

I wish I knew how
and I hope someone can enlighten me

jeffs

--
"Power corrupts
  PowerPoint corrupts absolutely"
-- Edward Tufte --
============

Prof. Jeff Sonstein

http://www.it.rit.edu/~jxs/
http://ariadne.iz.net/~jeffs/
http://chw.rit.edu/blog/
http://ariadne.iz.net/~jeffs/jeffs.asc
http://www.it.rit.edu/~jxs/emailDisclaimer.html

[Jo Rabin-2]

Folks, a gentle reminder that the document is in last call, so any
changes will ideally be "editorial".

I don't want to suppress anyone's keenness to address this topic, but
think that it may be too large a subject for an overview of this kind.

thanks
Jo

On 03/11/2009 16:28, Jeff Sonstein wrote:

> some good points
>
> On Nov 3, 2009, at 12:17 PM, Alan Chuter wrote:
>
>> Perhaps the word "alternative" is needed here, "If you need to use
>> canvas, then provide an alternative."
>
> I am not sure what that alternative might be...
>
>> updated as the image is redrawn, if that changes its meaning. How this
>> is done in canvas I don't know,
>> probably by the same script that updates the image.
>
> I am not sure I can see any other way to accomplish this than through
> scripting
>
>> Another solution might be to require that it be used in an
>> accessibility-supported way, as defined by WCAG [2].
>
> I am also not sure how to make a canvas object meaningfully accessible
>
> I wish I knew how
> and I hope someone can enlighten me
>
> jeffs
>
> --
> "Power corrupts
>  PowerPoint corrupts absolutely"
> -- Edward Tufte --
> ============
>
> Prof. Jeff Sonstein
>
> http://www.it.rit.edu/~jxs/
> http://ariadne.iz.net/~jeffs/
> http://chw.rit.edu/blog/
> http://ariadne.iz.net/~jeffs/jeffs.asc
> http://www.it.rit.edu/~jxs/emailDisclaimer.html
>
>

[Bruce Lawson-2]

On Tue, 03 Nov 2009 15:10:32 -0000, Adam Connors <adamconnors@...>  
wrote:

> In most cases Canvas is faster and should be preferred if it meets  
> requirements. However, since Canvas generates a flat bitmap it is not  
> inherently accessible and so should not be used as the sole means of  
> conveying information.
> -----  snip  -----
>
> my only teenie quibble
> would be with the last sentence
> which I think might better be changed from:
>
> "it is not inherently accessible and so"
>
> to instead read:
>
> "it is inherently not accessible as it is not part of the DOM, and so"

although work is slowly taking place on an accessibility API  
http://www.w3.org/html/wg/tracker/actions/133 so, while I'm aware that  
best practices are by definition a snapshot in time, we might want to note  
that it is *currently* not accessible?


--
Hang loose and stay groovy,

Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)
www.twitter.com/brucel

[Jeff Sonstein-2]

On Nov 4, 2009, at 2:13 PM, Bruce Lawson wrote:

>> "it is inherently not accessible as it is not part of the DOM, and  
>> so"
>
> although work is slowly taking place on an accessibility API http://www.w3.org/html/wg/tracker/actions/133 
>  so, while I'm aware that best practices are by definition a  
> snapshot in time, we might want to note that it is *currently* not  
> accessible?

I could live with replacing "inherently" with "currently"

jeffs

--
"when someone says it's not about the money — it's about the money."
- H. L. Mencken -
============

Prof. Jeff Sonstein

http://www.it.rit.edu/~jxs/
http://ariadne.iz.net/~jeffs/
http://chw.rit.edu/blog/
http://ariadne.iz.net/~jeffs/jeffs.asc
http://www.it.rit.edu/~jxs/emailDisclaimer.html

[Alan Chuter]

I would like to emphasise that my comments on this matter (of some weeks
ago now) should not be taken to call for any changes to the document and
I do not expect them to be addressed by the group.

best regards,

Alan



Alan Chuter wrote:

> The document says "Canvas ... is not inherently accessible and so should
> not be used as the sole means of conveying information." [1]
>
> Perhaps the word "alternative" is needed here, "If you need to use
> canvas, then provide an alternative."
>
> I think that as this is about dynamic graphics the document should also
> add the proviso that the alternative should be updated as the image is
> redrawn, if that changes its meaning. How this is done in canvas I don't
> know, probably by the same script that updates the image. Updates to the
> DOM (which would be used for the alternative) are detected by some
> current mobile screen readers. This also applies to SVG. SVG supports
> accessibility but in practice it requires a text alternative for the
> whole image.
>
> Another solution might be to require that it be used in an
> accessibility-supported way, as defined by WCAG [2].
>
> [1] http://www.w3.org/TR/mwabp/#bp-canvas
> [2] http://www.w3.org/TR/WCAG20/#accessibility-supporteddef
>

--
Alan Chuter
Departamento de Usabilidad y Accesibilidad
Consultor
Technosite - Grupo Fundosa
Fundación ONCE
Tfno.: 91 121 03 30
Fax: [phone]
achuter@...
http://www.technosite.es