- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Sun, 20 Mar 2011 00:21:14 +0000
- To: public-html-a11y@w3.org
- Cc: gez.lemon@gmail.com
aloha!
minutes for the first day of the HTML Accessibility Task Force
plenary meeting are available at:
http://www.w3.org/2011/03/19-html-a11y-minutes.html
as an IRC log at:
http://www.w3.org/2011/03/19-html-a11y-irc
and as plain text following this announcement -- note that the
media breakout session's minutes are located at:
http://www.w3.org/2011/03/19-media-minutes.html
thanks to all who scribed in both channels, gregory.
_________________________________________________________
- DRAFT -
HTML Accessibility Task Force Teleconference
19 Mar 2011
Agenda: http://www.w3.org/WAI/PF/HTML/ftf_2011-03
See also: IRC log - http://www.w3.org/2011/03/19-html-a11y-irc
Attendees
Present
John_Foliot, Silvia_Pfeiffer, Mike_Smith, Rich_Schwerdtfeger,
Masatomo_Kobayashi, Janina_Sajka, Denis_Boudreau,
Léonie_Watson, Steve_Faulkner, Eric_Carlson, Cynthia_Shelly,
Michael_Cooper, Joshue_O'Connor, Frank_Olivier, Judy_Brewer,
Sean_Hayes, Gregory_Rosmaita, Roger_Hudson
Regrets
Chair
Janina_Sajka, MikeSmith
Scribe
lwatson, Joshue, Gregory_Rosmaita, Rich, Leonie
Contents
* Topics
1. Text alternatives
2. Longdesc
3. ARIA Lexical Processing
4. CANVAS
5. Longdesc Redux
6. Open Issues
* Summary of Action Items
_________________________________________________________
<trackbot> Date: 19 March 2011
<richardschwerdtfe> Hi Gregory
<dboudreau> hi everyone
<dboudreau> greg! ça va bien?
<Zakim> oedipus, you wanted to ask if breakout session will use
#html-a11y-media or #html-a11y-2 ?
<oedipus> thought for the day: "It is much easier to slip into a
daydream than it is to think." -- Charles Willeford ("I Was Looking
for a Street")
<lwatson> scribe: lwatson
<oedipus> scribenick: lwatson
<oedipus> need both longdesc (external reference) and describedby
(in-document reference)
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs
<oedipus> a company or organization might have a collection of clip
art for use in site, with pre-canned ALT text and stable LONGDESC
reference which can be re-used ad infinitum
<oedipus> central control over images and image description
Text alternatives
SF: Issue 30 is being surveyed ATM.
JS We have given our recommendations on 80, 122 and 31.
<oedipus> lady of shallot:
http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/
JS: The question is whether we're satisfied with this, and whether
the right supporting points have been made?
<oedipus> GJR's change proposal is survey question 3
<oedipus>
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
<oedipus> TF proposal from TPAC:
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
<oedipus>
http://www.w3.org/html/wg/wiki/ChangeProposals/thematicimages
<oedipus> GJR's proposal reflects consensus reached at TPAC 2010 F2F
of A11y TF
<oedipus> TF proposal from TPAC:
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
SF: There is a response from me because the riginal bug was filed
against the alt text document, that required a change proposal.
... The chairs wanted to widen the scope, so the same message was
given across the spec and the alt text document.
<oedipus> lady of shallot issue statement:
http://www.w3.org/html/wg/tracker/issues/122
<oedipus> HTML WG ACTION 195 (propose replacement text)
http://www.w3.org/html/wg/tracker/actions/195
SF: There is an example of using an img of the Lady of Shallot. The
page contains the poem of the same name. The spec suggests the image
is therefore decorative, but the alt text doc says otherwise because
it adds to the thematic information.
... It shouldn't be mandidated that you can't provide an alternative
text.
RS: You have short names and long descriptions. There are different
vehicles for providing the short.
JS: To keep this in context, two years ago when we came up with our
consensus guidance we said there should be supporting documentation
and that it should coe rom WAI.
JB: Within the WAI co-ordination group, we spoke about getting this
moved to the WCAG WG. BTW, there is also work being started on this
by an external organisation that may result in confusion.
SF: The alt text document was developed to counter the normative
advice given within the spec.
<oedipus> GJR replacement text paragraph 1: "If an image is
decorative but isn't especially page-specific -- for example, an
image that forms part of a site-wide design scheme -- the image
should be specified in the site's or document's CSS, not in the
markup of the document."
<oedipus> GJR replacement text paragraph 2: "Exceptions to this
rule, in cases where CSS cannot be used to display an entirely
decorative image, are covered by the HTML5: Techniques for providing
useful text alternatives. [HTML ALT TECHS] Authors are also
encouraged to consult the Web Content Accessibility Guidelines 2.0
for more detailed information and acceptable techniques. [WCAG 2.0]
"
SF: If we move the alt text doc out to WCAG, we need a pointer
within the HTML5 spec.
<oedipus> steve, that is what my CP provides
SF: The main issue I'm concerned about, is that the advice in the
HTML5 spec is not authoratative.
<oedipus> HTML5 should point to WCAG as per my change proposal
<oedipus>
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
SF: Text alternatives are for more than people with disabilities.
JF: It's not who benefits, but where the guidance comes from.
SF: I would be more than happy if the guidance was maintained
outside of the HTML5 spec.
RS: When you put alt="" the spec should advice what the UA does with
it.
<dboudreau> I agree with you Greg. There should be a direct link
from the spec to WCAG
SF: It' the normative authoring advice that needs looking at.
RS: If an image has role=presentation should the rendering be the
same?
SF: Alt="" should be the same as role=presentation.
<oedipus> related: CP for definition of image (also agreed-to at
TPAC 2010:
http://www.w3.org/html/wg/wiki/ChangeProposals/first_2_paragraphs_of_defi
nition_of_img
<oedipus> my objection to role="presentation" was based on the fact
that HTML5 lacked a role attribute -- now we have one, no?
<Zakim> oedipus, you wanted to say that my change proposal points to
WCAG and SteveF's alt techs document for discussion of purely
decorative images after stating that should be controlled
RS: We could propose advice for UA as to what should happen when
images are turned off.
<richardschwerdtfe> yes, we will have a role attribute after our
discussion today. ... lexical processing of ARIA section
<oedipus> then i'm ok with role="presentation"
<Joshue> I think we turned a wrong corner when there couldn't even
be a consensus that image would have the role="image".
<oedipus> CP for definition of image (also agreed-to at TPAC 2010:
http://www.w3.org/html/wg/wiki/ChangeProposals/first_2_paragraphs_of_defi
nition_of_img
<oedipus>
http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images
MS: Not sure what Laura's position on this actually is. It would be
good if she could join the call.
<oedipus> GJR replacement text paragraph 1: "If an image is
decorative but isn't especially page-specific -- for example, an
image that forms part of a site-wide design scheme -- the image
should be specified in the site's or document's CSS, not in the
markup of the document."
<oedipus> GJR replacement text paragraph 2: "Exceptions to this
rule, in cases where CSS cannot be used to display an entirely
decorative image, are covered by the HTML5: Techniques for providing
useful text alternatives. [HTML ALT TECHS] Authors are also
encouraged to consult the Web Content Accessibility Guidelines 2.0
for more detailed information and acceptable techniques. [WCAG 2.0]
"
<Joshue> We meaning them (sic) and us (sic)
MS: Perhaps we should postpone discussion on this until Laura is
here.
JB: We probably souldn't hold up progress on this, as Laura may not
be able to make it.
<MikeSmith>
http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/results
<MikeSmith>
http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/
<MikeSmith> heh
JS: We previously voted GJR's proposal.
... Which leaves a second question of where this document/guidance
lives.
<oedipus> correct -- we decided at TPAC what to say, and i was
tasked to write it up as a ChangeProposal
SF: We were previously talking about role=presentation. James Craig
says this isn't appropriate, as per the ARIA spec.
JC: Is this just about where this document lives?
<Joshue> -q
CS: So the TF has a position on which position we go with?
<oedipus> can someone type cyns' question into IRC
<oedipus> ACTION: Gregory - submit comments on behalf of TF to
http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/ -
due 2011-03-24 [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action01]
<trackbot> Created ACTION-110 - - submit comments on behalf of TF to
http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/
[on Gregory Rosmaita - due 2011-03-24].
JS: Is there anything else we need to say here on alt, before we
move on?
<MikeSmith> yep
SF: We seem to be in agreement, but my one concern is that the
change materials the chairs will be reviewing doesn't necessarily
reflect the clarity we need.
SP: If someone has a decorative image, what's the recommended
approach?
<oedipus> Stevef, what additions do you deem necessary to the change
proposal for 122?
JF: It's a contextual answr, given in some detail in the spec.
<oedipus> GJR proposal says: if purely decorative, use CSS; if can't
use CSS, consult WCAG 2.0
SF: If it's purely decorative, then give it a null alt.
<oedipus> if purely decorative, use CSS to embed image
<JF> http://www.w3.org/TR/wai-aria/roles#presentation
<dboudreau> http://www.w3.org/TR/wai-aria/roles#presentation
<oedipus> if allow liberal use of <img src-"foo.jpg"
role="presentation"> will be offering an intollerable escape clause
-- purely decorative images should be handled via CSS and only with
role="presentation" in circumstances where CSS is not available
RS: role=presentation seems cleaner to me.
JF: We'll need to keep alt="" for backwards compatibility.
CS: We'll need both for at least the next five years or so.
<oedipus> need to say for "redundant" images (such as a mailbox and
the hypertext string "email us!" then the image can be
role="presentation" or alt="" but that is the only compelling case
for not using CSS for images (and even then, if an author is smart,
he/she can do this with CSS anyway)
DB: Is there a risk to using role=presentation that we'll need to
use role=information for images that are not decorative?
JS: It's presumed, so we probably wouldn't need to.
CS: That was a point of contention at one point, but has since been
settled.
SF: JC raised a question about alt="" and role=presentation. The
spec says if a decorative image with role=presentation is
encountered, remove it from the accessibility tree.
JS: What's the advice going forward?
SF: That *is the advice, and we haven't questioned this so far.
<Zakim> oedipus, you wanted to ask why aren't we saying use CSS to
control purely decorative images?
<oedipus> need to say for "redundant" images (such as a mailbox and
the hypertext string "email us!" then the image can be
role="presentation" or alt="" but that is the only compelling case
for not using CSS for images (and even then, if an author is smart,
he/she can do this with CSS anyway)
GJR: Why are we saying use CSS to control purely decorative images?
... We should say use CSS for decorative images full stop.
DB: You can't always do that.
<oedipus> janina, GJR replacement text paragraph 1: "If an image is
decorative but isn't especially page-specific -- for example, an
image that forms part of a site-wide design scheme -- the image
should be specified in the site's or document's CSS, not in the
markusp of the document."
<oedipus> janina, GJR replacement text paragraph 2: "Exceptions to
this rule, in cases where CSS cannot be used to display an entirely
decorative image, are covered by the HTML5: Techniques for providing
useful text alternatives. [HTML ALT TECHS] Authors are also
encouraged to consult the Web Content Accessibility Guidelines 2.0
for more detailed information and acceptable techniques. [WCAG 2.0]
"
MS: This is an issue for the change proposal itself, but with
regards to the spec the change proposal is advocating for haing the
spec reference some other txt/document.
... It's not an issue in terms of what we need to do for last call.
The text we're referencing isn't the issue.
<dboudreau> Greg, there are many situations in which you have no
choice but to put your decorative image in the html. I don't think
we can enforce that.
<oedipus> dboudreau, the second paragraph says, if you cannot use
CSS, then consult Alt Techs and WCAG 2.0
JS: We're dicussing issue 80 ATM.
... We have guidance on 80, the question is whether we stand by
this?
<MikeSmith> ack oedipus
http://www.w3.org/html/wg/tracker/issues/80
JS: We were against using title, if alt wasn't provied
SF: Don't think there has been any disagreement on this, and we had
a poll as well.
<Joshue> ISSUE-80 http://www.w3.org/html/wg/tracker/issues/80
<dboudreau> oh, i see. But then, refering to techniques, we should
find a reference to role="presentation" there if this is what we
agree on
<MikeSmith> http://www.w3.org/html/wg/tracker/issues/80
<oedipus> dboudreau, yes, definitely --
MS: Issues 80 and 31 are waiting for the chairs.
JS: Do we need to revisit this?
<oedipus> which CP:
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203 ??
CS: Our position has been stated, but issue 31 hasn't ben polled. Do
we know what the TF position is?
SP: That label isn't a good substitute for alt?
MS: There are a buch of change proposals for issue 31.
SF: We decided to put forward option 3 (perhaps 2) on this.
MS: Laura wasn't in agreement with this. Would be good to have her
input here on this.
<oedipus> SteveF, you are talking about
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203
right?
SF: If we're in agreement that the normative advice should be taken
out of the spec, our response to 31 should either include or
encompass that.
MS: It's a different problem. We do need to have normative text in
the spec. This is about the exceptions and what they are.
SF: What should the exception be if you don't have an alt attribute
on an image?
MS: In terms of the conformance/validator, what should be an
acceptable substitute?
<oedipus> hixie's change proposal for Issue 80 and Issue 31:
http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html
SF: Summary is that it's ok to h have role=presentation, alt="", or
a image with no alt and an associated figcaption, or
aria-labelledby.
JF: Did we have agreement with that?
SF: Yes, I think we do.
JS: We've discussed this sevral times and have always arrived at the
same place. We should mntion this in the survey.
<MichaelC> HTML meeting in Lyon
http://www.w3.org/2010/11/04-html-wg-minutes
SP: How does aria-labelledby and title fit into this?
SF: The consensus was that title shouldn't be considered a
conforming image, as far as the provision of a text alternative
goes.
DB: Is that because ATs don't support both?
CS: We feel it's the right way to do it.
SF: Historically, it hasn't been keyboard accessible - the
information might be important. It's a browser limitation, but it's
been known about for 10 years or more and there is no srong advice
in the spec about providing a text dscription is a device
independent way.
JF: When IE started putting tooltips in, the attribute values were
often duplicated causing information to be doubled up with some ATs.
<oedipus> @title often contains useful metadata (file type, size,
etc.)
CS: In the Lyon/TPAC minutes I can't find an agreement.
<oedipus> dboudreau, definitely need to push screen reader devs to
support both alt and title (in JAWS, one can set cascade of
attributes to expose)
<oedipus> but need to have a query for title and aria-label
<dboudreau> another problem with @title is that it's a hover effect
only (tooltip) therefore useless when using the keyboard only and on
mobile
<oedipus> dboudreau, agreed
SF: ARIA has no effect on the UA rendering of stuff. So you display
the content of aria-label means you're asking the UA to do something
extra. I'm not opposed to that, but that's the reason whay it's not
in the spec.
<dboudreau> greg, if we were to push them towards supporting both
attributes, then users wold get the info twice... pretty annoying
don't you think?
CS: Alt is rendered as a place holder, aria-label isn't.
<dboudreau> unless we could get mechanism that only reads the value
of @title when it's different form the @alt's value... but then
again, this is just another specific setting available in jaws
<MikeSmith> action Steven to send e-mail message to a11y TF mailing
list with a draft summary of the TF consensus position on what
exceptions should be allowed for alt-less images (e.g.,
role=presentation, aria-labeledby, etc.)
<trackbot> Sorry, couldn't find user - Steven
<MikeSmith> action Steve to send e-mail message to a11y TF mailing
list with a draft summary of the TF consensus position on what
exceptions should be allowed for alt-less images (e.g.,
role=presentation, aria-labeledby, etc.)
<trackbot> Created ACTION-111 - Send e-mail message to a11y TF
mailing list with a draft summary of the TF consensus position on
what exceptions should be allowed for alt-less images (e.g.,
role=presentation, aria-labeledby, etc.) [on Steve Faulkner - due
2011-03-26].
<oedipus> dboudreau, alt needs to be a functional equivalent of the
image being described, title is a hint/advice -- when i use both i
never use the same text -- validator should mark identical alt and
title strings assigned to a single element as an ERROR and instruct
the author to either use one or to change the value of one
<oedipus> validator should mark identical alt and title strings
assigned to a single element as an ERROR and instruct the author to
either use one or to change the value of one
SP: So I'm supposed to use alt as an author, and ignore the rest?
CS: No, they're different things for different situations.
<dboudreau> greg » i like that idea very much. from a validation
perspective this is good, but most authors won't validate therefore
won't be stopped by this
RS: When you write the overview, could you include somethig about
using aria-label?
<dboudreau> so while i do like it, i don't think it will be useful
or helpful enough for the end user
<oedipus> dboudreau, so ATAG needs to say "if author enters
identical value for @alt and @title, generate an error message and
query for different strings (alt for equivalent info, title for
extra metadata)
Longdesc
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs
<dboudreau> greg, i fail to see how this would prevent authors from
abusing both attributes with the same value
JS: There are two questions... Where and what. Let's take them in
reverse order.
<oedipus>
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Req
uirements_for_HTML5
JS: I suspect there is consensus within the TF to get longdesc back
in the spec.
<oedipus> laura's longdesc research:
http://www.d.umn.edu/~lcarlson/research/ld.html
JF: We've heard from lots of people that there needs to be a visual
indicator of longdesc, for sighted people who would benefit.
Longdesc was originally intended to be hidden. Browsers seem
reluctant to do this.
<oedipus> dboudreau, if author using authoring tool, that tool
should know to watch for and flag as error identical values for @alt
and @title -- sure won't help hand-coders like myself, but we seem
to be a dying breed
<oedipus> dboudreau, either that or threaten the author with "cruel
and unusal punishment"
JF: Several browser vendors have epressed an interest in creating a
visual indicator plugin of some kind.
s/rpressed/expressed/
<oedipus> tools that support LONGDESC:
http://www.d.umn.edu/~lcarlson/research/ld.html#tools
<dboudreau> you may be right... but i'd be reluctant to suport this
knowing it would end up meaning redundancy for end users.. i'd
rather go with the threat and personnaly dliver it myself (if we
have the budget) <grin>
<oedipus>
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Implementation_Infor
mation_for_LONGDESC
<oedipus> dboudreau, my idea would only work with additions to WCAG,
ATAG and UAAG (expose all metadata)
JF: If the browsers themselves can't close the loop, perhaps ATs
will
... If the browsers themselves can't close the loop, perhaps ATs
will?
JB: Can you give some examples of the use case for a visual
indicator?
<Joshue> I agree with Judy about use of a @longdesc plugin..not mad
about the idea.
<oedipus> longdesc not only for blind -- cognitive users may be
assisted by a guide to the complex image as would those with very
limited viewports
JF: People with disabilities that mean they would benefit from the
additional information held in a longdesc.
<oedipus> longdesc exposure and exposition should NOT be an AT
thing, but a UA thing
<Joshue> +1 to GJR
JB: Browser plugins seem like a comprimised way of dealing with
this.
<oedipus>
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Use_Cases
<dboudreau> I also believe we should work to have longdesc supported
by the UA, not the AT... UA means more people can benefit form it
<oedipus> dboudreau, amen, brother!
JB: How much as the TF looked into the use cases?
<Joshue> Longdesc shouldn't be a second class citizen in the
browser.
<oedipus> plus 1 to JOC
JB: If one of the reasons the browsers are pushing back is because
the use cases aren't strong enough, perhaps the TF should strengthen
the case.
<oedipus> judy, laura and i have tried to structure
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs to reflect
what the chairs told us they wanted explicated
RS: Rather than a plugin, have you asked the browsers about an
option within the settings?
<Joshue> A configurable option in the browser isn't a bad idea. +1
to RS.
JF: The functionality is available through the contextual menu.
Screen readers also have a mechanism for giving the user a choice of
whether to access the longdesc.
<oedipus> plus 1 as well -- user needs to know longdesc available --
should be able to put images with longdesc into the tab-navigation
order so it is easy for the user to access
JF: One of the prolems with longdesc is that developers don't see
it, potential cause for longdesc etc. If we make it visible, it has
to go in one of two places. A plugin will give us proof of concept.
<oedipus> JF, note that one can only get longdesc info from a
graphic if one lets the whole page be spoken or if one navigates
from graphic-to-graphic when using screen reader
RS: The concern I have is that the people who need a visual
indicator, is that a plugin will be difficult for the people who
would most benefit from the functionality.
<oedipus> UA needs to allow users to add images with longdesc to the
tab navigation order for the page
<Joshue> +q
RS: Let's put the use case together and explain that the UA should
provide a visual indicator.
<oedipus> visual indicator should be an option not a requirement or
default setting
JF: Longdesc is a DOM node. As ar as supporting the browsers goes,
it's ther. It's what the visual browsers do with this information.
<oedipus> author can assist with CSS applied to image with longdesc
<dboudreau> Laura's research on londgesc is 121 printed pages long.
How much stronger does our use case really needs to be?
MS: The issue is whether longdesc should be conforming. It will
still work, it just won't validate.
<oedipus> dboudreau, i've been wondering that myself
<Joshue> -q
JF: The title attribute was for advisable information, but it was
never specified how that should be presented to the user. The upshot
was that it became a tooltip, but that was just the path chosen by
the browsers. We'll have the same thing with longdesc.
<Joshue> +q to say that I don't agree with the longdesc POC
approach, the requirements and use cases should be defined first and
then clearly defined in the HTML5 spec. The plugins etc already
exist, more of them won't help the issue.
RS: We could say that to support longdesc the UA must provide a
facility to allow the user to have visual indication that longdesc
is available on the element. Also that it must be a high level
vehicle.
SF: I agre, but we won't get a "must" in there.
... There needs to be device independent access to the title
attribute, and we've been told that can't be mandidated. We can't
say that the UA is "required" to provide access to an
element/attribute/information.
<oedipus> visual indicator should be an option not a requirement or
default setting
JB: This isn't going to be something that gets unanimous consent. We
need to articulate what we need clearly.
JF: We'll get "should", but probably not "must".
<oedipus> UA MUST provide access to and indication of LONGDESC, but
a visual indicator SHOULD be an option not a requirement or default
setting
JB: That may not be the case. It may need to be an override.
... I wanted to speak to the timing, which is the trickiest part of
our strategy. It could play out in many different ways. We could for
example have this first on the queue after the last call is issued.
RS: Would the IE team be open to the idea of a visual indicator?
<oedipus> yes, rich, but not by definitionault
CS: I'm not on the IE team, so can't speak for them, but it may be a
challenge.
<Stevef> oedipus: can you point me to your long description wiki
page?
<oedipus> SteveF, which the verbose descriptoin reqs or the original
HTML WG page on longdesc?
EC: Same thing for Safari. The feedback from users is to put less
chrome in front of us.
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs
JF: There is a timeline of implementation. a plugin is the "cheap,
easy and beautiful" option. If we can prove there is a need and the
browser vendors can see the download data, it adds to the use case.
JB: So it wouldn't interfere with the chrome?
<oedipus> http://www.w3.org/html/wg/wiki/LongdescRetention
<Joshue> -q
RS: EC, do you have a notion of whether a plugin might e considered
by Apple/Safari?
JS: Does this need to be a user action, the browser could action an
auto-download.
CS: That opens up questions over security.
<Zakim> oedipus, you wanted to say as a reminder -- longdesc is a
"make or break" issue for EPUB 3.0 compatibility with HTML5
<oedipus> GJR wants to address urgency of longdesc and describedby
-- EPUB can't wait until Last Call, but needs a decision now to keep
it aligned with the HTML5 spec as requested of the HTML WG Chairs by
George Kerscher, Jim Fructerman and Geoff Freed
<oedipus> i can't hear you either -- put comments into IRC
GJR: There is some urgency on this. The important thing is that ePub
badly wants longdesc in HTML5.
<oedipus> judy, yes, i'll get URI
JB: That's the same reference as in the Diagram Project letter.
DB: Usually when you can't find agreement, you need to look at it on
different levels, not just technical.
JB: Yes, it is being looked at on multiple levels.
<oedipus> G Freid on behalf of DIAGRAM project to HTML WG Chairs:
http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html
JB: There are various mechanisms we can look at. The requirements of
last call require that things need to be fully addressed, so there
is a question that the spec should go to last call now.
<oedipus> s/Fried/Freed/G
DB: I'm not sure we'll get it through using the usual channels.
JB: We do need to respond to the points that were raised, and to
justify very clearly out position.
JF: It seems to me we've covered most of this withour change
proposal, is there more we can add to this?
JB: Another problem I see, it isn't fully clear what the proposal on
the table actually is. We're not all fully co-ordinated within the
TF. The chairs would also like to see dialogue between the TF and
the people who are opposed to restoring longdesc.
JF: We need to address the fact that longdesc will throw a
validation error.
<oedipus> what is justification for opposing restoration of
longdesc? i mean the REAL justification....
SF: That's actually a very small change.
JB: My impression is that more was needed for clarity. Does Laura's
prposal include everything we need?
... The chair's impression seems to be that not everyone within the
TF even agrees about restoring longdesc. Removing that confusion
would give clarity.
JF: We;ve covered longdesc at previous F2F meetings.
SF: What we have unanimity on is that there needs to be a dedicated
method to providing a long description.
<oedipus> HTML5 lacks a verbose descriptor mechanism (HTML bug
10052) includes requirements:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853
JB: The technical proposal needs to be the best we can do, and this
opens up other options for how its followd through.
<oedipus> requirement 1: A programmatic mechanism to reference a
specific set of structured content, either internal or external to
the document containing the described image
<Zakim> oedipus, you wanted to ask if describedby will be simply
describedby or aria-describedby?
JF: So, what do we need to do now? We don't have longdesc in the
spec, and the chairs have told us they won't discuss it until aftr
last call.
JB: If the chairs did put this first in queue, feedback from the TF
on what we think about that would be useful to know today.
<Zakim> oedipus, you wanted to ask if describedby will be simply
describedby or aria-describedby and to ask if describedby will be
simply describedby or aria-describedby in HTML5? is the
<oedipus> i'm ok with discussing later
SF: As far as ePub is concerned, what is their requirement? Do they
require a specific method for providing long description?
<oedipus> SteveF, yes
<dboudreau> greg, if we removed the aria prefix, wouldn't it cause
confusion? using describedby in html5 and aria-describedby in any
other language?
<Joshue> A good question is to try and understand why is there the
opposition to longdesc in HTML5 in the first place.
JB: Their primary concern is that longdesc is gone, after a decade
or more of support.
<oedipus> SteveF, DIAGRAM/EPUB request
http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html
<MikeSmith> let's take a break in 5 minutes or so
SF: So simply making it a conforming attribute would be sufficient
for ePub?
<Joshue> +1 to MS
<oedipus> dboudreau, good point, but if aria is included as part of
HTML, then the aria- prefix doesn't make sense
<oedipus> in the HTML context, that is
<dboudreau> joshue, there is oposition because some feel that since
it's never been implemented properly by brosers and authors ailways
used it wrong, it should be replaced by a better mechanism
JB: So, how can we be responsive to the concerns and to the user
needs? If there is a way to evolve it to a configurable option, that
would be good. If the TF could write out that path, that would also
be helpful,
<oedipus> joshue, bogus web-usage statistics
<Joshue> db, yes I know that but its not a good enough reason IMO
SF: If it were brought back to conforming, there would be lots of
way to look at the rest and create proofs of concept.
<oedipus> plus 1 to SF
<Joshue> oedipus, lol. He who makes the stats makes the rules..
<dboudreau> removing @longdesc based on this is pretty much like
saying we should remove h1 because most authors use <p
class="pageTitle">
<Joshue> +q
SF: It's the semantic indication that there is a longdesc, the
mechanics are open.
<oedipus> requirement 1: A programmatic mechanism to reference a
specific set of structured content, either internal or external to
the document containing the described image
<oedipus> HTML5 does not provide the functions that had been
provided through the HTML 4 attribute longdesc. Those functions are:
1. A direct, reusable programmatically determinable mechanism to a
long description of an image without a forced visual encumbrance or
default visual indicator. and 2. A method to reference a longer
description of an image, without including the content in the main
flow of...
<oedipus> ...a page
JB: To come back to DB's question... The fact there is long
documentation isn't perhaps as relevant as *what we provide. Does it
specifically defin use cases, and (as the chairs would like) does it
address each point very clearly. If I can be of help in looking at
the presentation of the response, I will.
JS: Are we generally agreed with this proposal, to take it as a
first last call issue?
+1
<dboudreau> +1
JS: Let me summarise... At the time they published last call, there
will be a list of issues with the spec. At the top will be longdesc,
and a committment from the chairs to look at this as the first
priority.
JB: I think there is a misunderstanding on the chair's part that
there is strong dissention within the TF about restoring longdesc.
There hasn't been any of that dissention within this discussion
today. Am I hearing right?
RRS: I was a dissenter, but I'm happy to go with the flow.
<oedipus> the chairs made a mistake in removing something EXPLICITLY
added to HTML4 as part of the director's mandate on accessibility
WITHOUT proposing an equivalent or superior mechanism, nor even the
recognition that this functionality is needed
<oedipus>
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Req
uirements_for_HTML5
SF: It's important that if it is restored, the spec clearly explains
a mechanism for how it should be implemented that improves on the
current HTML4 implementation.4
<oedipus>
http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Reinstate_longdesc_a
nd_Add_a_Native_describedby_Attribute
<oedipus> Judy, a lot of this discussion was held up until the
ARIA-in-HTML decision was issued
<oedipus> still feel strongly we need to state in this case (and in
other, summary comes to mind) the chairs made a mistake in removing
something EXPLICITLY added to HTML4 as part of the director's
mandate on accessibility WITHOUT proposing an equivalent or superior
mechanism, nor even the recognition that this functionality is
needed
JS: Returning to GJR's question about what last call means... The
proposal is that in May there will be a last call that includes the
publication of the spec. Longdesc will not be specified in there as
conforming. There will be a statement of known issues, and longdesc
will beat the top and the committment is there to take that up as
the first issue.
<Joshue> +1 to GJR, right on.
<oedipus> i can't speak on EPUB's behalf without pinging at least
marku
JS: At the end of that process, approx. 30 days, there will be an
updated last call spec that would include the disposition of that
review.
<oedipus> thanks, janina
JS: I understand ePub's concerns, we're often asked to hurry alog
because people need/want to use our specs.
<Joshue> -q
<dboudreau> -q
<oedipus> many thanks to leonie for minuting
<MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2011-03
<Joshue> Scribe: Joshue
ARIA Lexical Processing
RS: There were couple of topics refs to role model, we have to say
where role is defined.
MC: Or define it in that section, I would like role to be a global
att
<oedipus> NOTE: section 3.6.2 is now section 3.6.7
http://dev.w3.org/html5/spec/content-models.html#annotations-for-
assistive-technology-products-aria
RS: Ok
MC: If not we can define in the proposed section.
RS: You want to define it in just ARIA
MC: I don't think the HTML 5 wants to.
<oedipus> plus 1 to MCooper -- defined in 3.2.7 as defined in
WAI-ARIA, role global attribute for HTML5 with possible exceptions
RS: Also HTML 5 has booleans, true etc. ARIA not defined that way.
<oedipus> what about the redundant stuff in ARIA that was for
plugging holes that may be plugged by HTML5?
RS: A checkbox can have true,false, mixed for example, so we don't
limit it in the same way as HTML5
... So we have to define the processing of ARIA?
... Mike, you wrote the section how should we proceed?
<oedipus> NOTE: section 3.6.2 is now section 3.6.7
http://dev.w3.org/html5/spec/content-models.html#annotations-for-
assistive-technology-products-aria
RS: I know that DAISY eg would like to provide diff roles.
MC: Don't know what to do about that, for ARIA we want the role @ to
support the various roles.
<oedipus> EPUB wants to support ARIA roles and RDFa roles
MC: We could propose the att with expanded values.
RS: Lets have a look.
<current ARIA lexical doc being looked at>
MC: I suggest adding role to the list of global attr in the current
HTML5 editors draft.
<oedipus> are we looking at:
http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5 ???
the phone is down on your end
RS: Thats prob a good place
<Stevef>
http://www.html5accessibility.com/tests/aria-changes.html
RS: What is the role attr state? CR?
MC: The HTML WG don't want to reference the ARIA role attr model
<Stevef> oedipus: have marked the chnages using ins @ del elements
don't know if you can pick that up
RS: It has to be a space delimited list
MC: For sure
RS: We should take text from the role attr module and tailor it
MC: Yes
<oedipus> SteveF: now that you told me what to have my SR look for,
i should be able to find them -- you might add a note to the text
for others, though
<group looks at ARIA section of spec>
<Stevef> sur
MC: We need to define all of the ARIA attr in HTML spec.
<Stevef> oedipus: will do
MC: HTML doesn't defined elements by reference..
<oedipus> http://www.w3.org/TR/role-attribute/
<oedipus>
http://www.w3.org/TR/role-attribute/#s_role_module_attributes
CS: We are waiting for Ian to complete his Action item.
<oedipus> "The attribute describes the role(s) the current element
plays in the context of the document. This can be used, for example,
by applications and assistive technologies to determine the purpose
of an element. This could allow a user to make informed decisions on
which actions may be taken on an element and activate the selected
action in a device independent way. It could also be used as a...
<oedipus> ...mechanism for annotating portions of a document in a
domain specific way (e.g., a legal term taxonomy). Although the role
attribute may be used to add semantics to an element, authors should
use elements with inherent semantics, such as p, rather than
layering semantics on semantically neutral elements, such as div
role="paragraph"."
RS: Ian send a note about ARIA normative, I don't want to limit HTML
5 to what is in ARIA 1.0.
MC: If we can incorporate by reference thats fine.
MS: Thats what is done, MATHML eg
MC: We do need to map value types.
JOC: Not referencing a numbered version would help.
RS: Yup
... If ARIA is to define new roles, that they be limited to elements
that do not restrict the roles they can be applied to.
<looks at screen of ARIA role and value type>
MC: They need to be copied, I can do this via XSLT.
... We are just not using the HTML boolean type, just using them as
token types.
CS: We need to be explicit about that.
MC: We want to expand that note, and make it an editors note.
RS: Start with role?
MC: Yes
<oedipus>
http://www.w3.org/TR/role-attribute/#s_role_module_attributes
<group reviews current draft>
RS: The role attr takes this value.. lets not use a CURIE, we should
take a string?
MC: I suggest a token.
<oedipus> plus 1 to token
MC: Looking at micro syntaxes, we want space seperated tokens.
RS: Yes, we do.
<oedipus> plus 1 to space separated tokens
<some spec cpy n pste going on>
<some editing going on>
<look at XHTML vocab>
<oedipus> http://www.w3.org/TR/role-attribute/#bib-XHTML-VOCAB
<oedipus> http://www.w3.org/1999/xhtml/vocab
RS: Are we going to sync with ARIA implementation guide? Steve?
... We will prob define mapping in ARIA 2?
CS: The guide are seperate?
RS: Yes, knew roles are features are defined, don't want to be glued
to version number.
... How do we define the processing of the role values?
CS: So if ARIA has new roles?
RS: Say, EPUB and DAISY etc, re ARIA 2 we want to say the value
mappings are defined in an external reference. HTML to platform A11y
API Implementation Guide.
... If new roles are created
CS: In a later version of ARIA
<oedipus>
http://www.w3.org/TR/role-attribute/#extending-the-collection-of-roles
RS: I want to say that those roles in ARIA are not restricted.
CS: Don't know about that, or you will only use them on <divs>
<oedipus> "It is possible to define additional role values. Such
values must be defined in their own vocabulary. The URI associated
with that vocabulary should resolve to a resource that allows for
the machine and human discovery of the definition of the roles in
the vocabulary. One format that achieves this is the RDFa Profile as
defined in [RDFA-CORE]. Note: If this attribute is used in
conjunction...
<oedipus> ...with RDFa (see Appendix A), then the vocabulary
definition must be the same as that required by RDFa."
CS: We don't want to say that only certain elements etc would accept
ARIA roles etc
... I want to say that there is some restriction to new ARIA roles.
SF: This refers to strong native semantics and implied semantics..
MC: We have three external and two internal refs..
<oedipus> do we want to align role extention with RDFa-Core?
http://www.w3.org/TR/2010/WD-rdfa-core-20101026/
RS: So if we define new ARIA roles we have to update the
implementation guide?
MC: Yes
RS: Perfect.
CS: But no that duplicates the funcionality of the implementation
guide?
RS: We just need to point to mapping for any new ARIA updates.
<some confusion about what docs are being referred to>
MC: Yes, the WAI-ARIA User Agent Imp Guide..
CS: Yes, we can edit that at will.
RS: So there won't be a ref to implementation guide?
... Will will need normative references to the UA guide?
MC: Yes, we have that now.
CS: So how about something that states new ARIA roles cannot be
applied to elements that do not allow override?
<more spec wordsmithery>
<oedipus> using role in conjunction with RDFa
http://www.w3.org/TR/role-attribute/#using-role-in-conjunction-with-
rdfa
RSSAGENT, make minutes
<oedipus> "If a Host Language contains the @role attribute, then an
RDFa processor processing a document written in that Host Language
according to the rules of that Host Language may generate additional
triples for role attributes. If these additional triples are being
generated, then they must be generated as follows:"
CS: We don't want to be too restrictive..
RS: There may be a fight.
... Ian asked about what is normative, I think we have to do this.
CS: If we make an ARIA overide at some stage, we need to be able to
add that.
MC: Getting the group to agree to externalise this section would be
good.
CS: I agree.
SF: We want Steves annoteted doc externalised
<oedipus> cooper, by externalize, do you mean split off into a
separate document, like the Alt Techs doc?
s/annoteted/annotated
<discussion on overrides etc>
<oedipus> won't we be accused of cyber-ghettoization?
SF: Ian did say that role="presentation" can be on anything.
RS: Yes
... Two things, we need to say what happens when ARIA introduces new
roles.
... Also what happens when a role value is provided if not listed in
HTML5 spec
<oedipus> on ANY element? <head role="presentation" > doesn't make
any sense... is there an exception for elements that appear in the
HEAD
MC: They might want a conformance warning..
CS: Yes
MS: Currently I don't think the spec does define this.
... It does say role attr * etc can be used
<oedipus> spec should at least limit role="preentation" to elements
that occur in the BODY of a document
<oedipus> er, role="presentation"
MS: I don't see a restriction on what can be implemented in
validator.
MC: ARIA 1.0 does say take the first recognised token..
... Then ARIA spec say all it needs to.
RS: So are we ok with ARIA role def?
<oedipus> what is the ARIA role def -- as tweaked today?
<more word smithery>
MC: If we externalise this stuff we can fix more easily
RS: If we wish to add new role values, etc we wish to state it would
not create a conformance error?
MC: Don't really mind, to have warnings may not be ideal.
<oedipus> RS, as long as the role value is documented as per Role
Attribute verbiage
<oedipus> "It is possible to define additional role values. Such
values must be defined in their own vocabulary. The URI associated
with that vocabulary should resolve to a resource that allows for
the machine and human discovery of the definition of the roles in
the vocabulary. One format that achieves this is the RDFa Profile as
defined in [RDFA-CORE]."
<discussion of other use cases>
<oedipus> "Note If this attribute is used in conjunction with RDFa
(see Appendix A), then the vocabulary definition must be the same as
that required by RDFa."
http://www.w3.org/TR/role-attribute/#using-role-in-conjunction-with-
rdfa
<more discussion on implemtation guide etc>
s/implemtation/implementation
MC: This is kinda like microformats, we need an interoperable web..
RS: Regarding DAISY etc, they may ignore these warnings.
<discussion on EPUB etc>
CS: They should come up with there own schema
<oedipus> EPUB wants to ensure that it is as close to HTML5 as
possible so as to allow rendering of EPUB content in HTML5-capable
UA
MS: In HTML 5 we have no normative schema.
<discussion on RELAX NG and spec schema etc>
<oedipus> cyns, EPUB will come up with own, if can't get from HTML5
-- point is, they'd rather not have to come up with their own, but
reuse native semantics
MS: The EPUB group were concered about developing their own schema.
<more word smithery>
MC: The values that are allowed changes by element.
RS: Is the title going to remain?
<discussion on Stevef's doc title>
The 'Annotations for Assitive Technology' doc
<oedipus> break now for lunch or are we continuing through lunch?
<oedipus> s/break now for lunch or are we continuing through
lunch?//
<oedipus> can i step away for a break or are we coninuing? if a
break, how long?
<oedipus> er, continuing
<oedipus> dboudreau, the reason we didn't make describedby capable
of taking an external URI was: 1) we thought that LONGDESC already
did that and liked the solutions offered by SVG (namely, a container
into which structured content could be put) and 2) when it did come
up as a potential replacement for LONGDESC, ARIA was already
finishing its second last call period, and making the change to...
<oedipus> ...describedby would have necessitated a return to Last
Call, when we REALLY want to get ARIA through CR!
<oedipus> s/already finishing/already in/
<oedipus> HTML5 Section 7.2 - "Activation"
http://dev.w3.org/html5/spec/editing.html#activation
<oedipus> HTML5 Section 7.3 - "Focus"
http://dev.w3.org/html5/spec/editing.html#focus
CANVAS
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas
SF: Regarding the mapping doc is there a prefered place for that?
MS: In the ARIA section.
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals
MC: I should do a CP
... I would like to take over the doc that Steve has been editing.
... I will then do a proposal with suggested additions etc
<Stevef>
http://www.html5accessibility.com/tests/aria-changes.html
RS: Are we doing to have a what ARIA dot (incremental) version?
<oedipus> Stevef, do you have any comments on HTML WG Bug 10905 -
clarify how assigning an accesskey to an element affects the
elements default role filed by Steve Faulkner
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10905 for
http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs#Bugs_marke
d_RESOLVED_WONTFIX
MC: We haven't decided yet
<Stevef> oedipus: will look
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals
RS: Re: canvas, we have a CP out now. We'll talk about hit testing
for a11y APIs.
... It would be great to have someone from Apple to float some
concepts about clickable regions.
<oedipus> scribe: Gregory_Rosmaita
<oedipus> scribenick: oedipus
<trying to find participants for discussion>
MC: agenda has media people in breakout for most of 2 days
... could see if GJR ready for Access discussion
http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs
most of them have status reports
RS: returning to CANVAS
... problem: for a11y and authors -- very difficult to do clickable
areas for authors (hit testing)
... want to introduce concept of clickable region as have in
windowing system -- dates back to windows 3 -- when draw to desktop,
have device context (font, color, clipping region, bounding
rectangle)
... when click on screen app in windows calls into app (hit test) --
if child in there, keep going through -- know clicked in area -- not
a concept contained currently in CANVAS
... what you can do is...
... fills rest of gap we have
<rich looks for slide from CSUN presentation>
RS: <adjusts screen resolution>
... function call -- find clipping region
... then say setClickable Region and set that in canvas subtree --
when click in clicakble region, you would operate off DOM to get
coordinates and bounding box
<Joshue> CS: Microsoft did a demo of <canvas> a11y yesterday in IE9
SF: focus management question -- want checkbox kbd accessible
RS: is kbd accessible
... now can have clicks and kbd support -- nice and clean
SF: getting method for using canvas subDOM different from dev to dev
RS: talked about CSS -- problem is transformations that canvas does
-- don't have to do that with proposal
... worked with Charles Pritchard on this -- problem clickable
region support
... whatever UA does...
<room dropped from call>
<Joshue> <discussion on Richs idea for new canvas API>
RS: does all transformations without additional overhead
... do people like this approach?
<general approbation>
RS: so can i advance this?
<yes>
<Joshue> +1 to Richs idea
plus 1 to advancing RS' idea
RS: problem with CSS is transformations issue
... limited by tools at disposal
... hit testing a trip down memory lane...
... can do before LC? re-definig clickable regions -- bigger than
a1yy
s/a1yy/a11y/
s/re-definig/re-defining/
the only one i can't hear is MikeSmith
now i can't hear anyone but Cyns
RS: click goes to first thing, then bubbles up
... what you click on has to start at some element, probably lowest
level of DOM
... if MikeSmith could write up what he just said, that would be
great
CS: remember computation on that level -- don't want to increase
burdens
<MikeSmith>
http://dev.w3.org/html5/spec/infrastructure.html#event-click
<MikeSmith>
http://dev.w3.org/html5/spec/references.html#refsDOMEVENTS
<MikeSmith>
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
Activation in HTML5:
http://dev.w3.org/html5/spec/editing.html#activation
focus in HTML5: http://dev.w3.org/html5/spec/editing.html#focus
MS: what happens if have touch device?
... actuation method of DOM (couldn't hear)
... <reads from something>
RS: have to say bounds of element are defined by <unintelligible>
... if setClickable region, bind to that element, that section is
defined based on what is associated with that element in the DOM
<MikeSmith> ok
RS: this is region associated with that handler
... if click in any of those areas, possible to hit test to get
bounds
... if we could get text for the spec, that would be good
<scribe only getting disassociated words>
MS: event is fired as whatever elment clicked on
RS: determines what click on
MS: what is method to capture event?
CS: if put in method to get caret <couldn't hear>
... if event listener catches event, does the job
RS: UA directs mouse to child --
<can only hear individual words>
RS: i'm going to associate clipping region i have to define how that
object associated with that clipping area is determined <couldn't
hear>
CS: whatever you bind to -- even a parent that gets clipped -- still
works
RS: problem is on normal web page -- you clip, you know the DOM
target, but on CANVAS, need to find a way to map that area to that
object and properties
... layout engine does this anyway, but doesn't specify how to
determine <couldn't hear>
... are TF members ok with this approach?
<can't hear>
RS: even though specify rectangle, canvas doesn't take rectagle --
can use an ellipse or other more complicated shapes
... setClickable.Region to passive
<can't hear due to white noise>
CS: if do for anything other than rectangle what will happen?
RS: can be triangle
CS: need to define shape first?
<click where?>
RS: a11y api purposes, use rectangle or triangle
CS: if tab, going to get focus rectangle
RS: focus.screen can be circle, ellipse
<click where?>
CS: if use recatagnle to bind event handlers, how would that impact
<couldn't hear>
RS: this is canvas, not "straight HTML"
<Joshue> s/ recatagnle/rectangle
RS: specify this using wording
... have to have function that says, based on viewer and DOM tree
that that position is in that clicable region
... pick lowest point of DOM tree that has highest lean-over
CS: how do you fix?
RS: have to have different rule for defining other than rectangle
<discussion between Cyns and RichS on canvas versus HTML and binding
shapes>
<remote scribe can't hear flow of conversation>
CS: worry is getting it implemented
RS: clean way to do hit testing
... bind canvas to object use what have in HTML to bind object
fallback content with drawing path exposed via canvas --
... cleanest way to support a11y API because don't have to do
transformations in CSS to reproduce transformations in canvas
CS: understand RS point
... want it documented
RS: nothing new -- this is a "rich drawing space"
CS: can be different shapes
RS: yes -- requires author-end work
<can't hear very clearly>
<can't hear discussion>
<scribe thinks Rich and Cyns are discussing implementation issues>
<heard rich say "squiqqly">
<er, squiggly>
<richardschwerdtfe> can you hear me?
yes
<cyns> I said that moving from the html rectangle-only hit testing
in browsers now to arbitrary paths may be a lot of implemenation
work
RS: diff between hit testing in canvas and on HTML is largely like
desktop -- do hit testing within rectangles, so is trivial thing to
say whether this piont is in bounds of rectangle
... however, can have squiggly path that is closed, but not uniform
in terms of trectangle -- finding out if click in path is more
challanging -- is that going to be a problem for UA devs
... currently all of that is handled by canvas author
... when looked at DOM event spec did not define how it knew when
position within bounds of the element that you were trying to click
on
... can have things like an option in listbox -- how do you know you
are within option in list box -- send to listbox or listbox
container
... cleaner, but redefines what is not clearly defined in DOM Events
spec for how do DOM hit test
... no other way to do this right now --
... whatever shape provided, have to do "best fit" rectangle for the
a11y object because only use rectangles in a11y API
CS: sounds like could be a lot of extensive implementation work --
poetentially destablizing -- expect vendors to be wary of that
RS: bring this back to discuss with Frank Oliver
MichaelC, are you luring FrankO to RichS with chocolates?
<richardschwerdtfe> :-)
CS: what happens when canvas area is non-rectangular?
<can't hear FrankO>
CS: put click handler on canvas DOM
MichaelC, should this be minuted -- can't hear -- 2 discussions at
once
RS: have method in canvas for pointing to path -- work for key
order?
MC: plenary stuff for afternoon
... look-up table auto-generated for aria state and property looks
up HTML ValueType
RS: if we define new property?
MC: regenerate it
... why want to externalize section of spec, so can update it
indepently
MS: people can disagree, but don't think it is a non-starter
CS: initial resistence, perhaps
RS: don't want to waste cycles spinning own wheels
MC: need lookup table like this
... demand for it
RS: why not keyword enumerated values as defined by Blah
... i can have aria values defined as this this and this -- keyword
enumerated values -- what aria defines in spec today
... if have space delimited token list, have another one
... IDREFs another type
MC: that is data lookup table would provide
... do you want into organized by HTML type and aria attributes that
apply?
RS: want to avoid having another document
... in aria subsectino define diff types -- for types, here how to
process
... whitespace
... how to deal with whitespace
MC: doesn't use that term any more
RS: for IDREF, what would you call it?
MC: defined in mapping table
... IDREF is the value of a defined id value on another element --
most precise concept can find in HTML5
RS: so refer to IDREF, point to that
... don't have to id all individual attributes -- all the attributes
refered to in ARIA section...
section 3.6.7 in current editors' draft
RS: IDREF defined in this section of the aria spec is processed as
follows
MC: what have now
... defines what to do in HTML
RS: ok, but didn't like, because?
MC: if user agent implementor and implement ARIA state and property
attributes -- hear values -- don't want substitutions or stopping
because doesn't know what to do, so would have the link that takes
you to the table that is intended to be generated
RS: why not just put that table in the HTML5 sperc
MC: intend to
... can do that -- don't know if would satisfy,
... want to hear what HSivonen has to say about it --
RS: where do we have true/false enumerated values
... refer to true/false in table -- in atomic data type?
MC: <shows RS table (i think)>
RS: perfect!
... these are the diff types as defined in aria, this is how
processed in HTML, and put the table in it
... put in Annotations for Assistive Technologies (ARIA) section
MC: or make informative external reference
RS: has to be processable
MC: everything specified -- do you know where to look for it
... do need to know spec well enough to follow a link
RS: put somewhere in this section "WAI_ARIA is a cross-cutting
technology. Therefore, the actual implementation of aria must be
specified for each host language. For HTML here is the
implementation:"
... don't want to have to have any change to ARIA contingent upon
any other group's processes
... who has change for this section?
MC: definition for role attribute
RS: primary change proposal
potential ACTION for Cooper - take SteveF's Lexical Processing
prose, add definition of @role, and propose as change proposal
<scribe> ACTION: Cooper - take SteveF's Lexical Processing prose,
add definition of @role, and propose as change proposal [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action02]
<trackbot> Created ACTION-112 - - take SteveF's Lexical Processing
prose, add definition of @role, and propose as change proposal [on
Michael Cooper - due 2011-03-26].
RS: want to get feedback on default roles for elements in HTML5 --
do we need? should we do a longdesc -- remotedesc?
... want to know what to plan for ARIA.next
... like to start circulating a list; would be fine if response is
"we don't need anything"
<discussion of whether to intrude on media breakout group or
continue with other agenda items>
MC: media group wants to continue current work
http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs
MC: timeline review and writing change proposal -- how much time?
MS: walk through of chairs' decision policy
MC: should open to everyone
<Stevef> as per earlier discussion
http://www.html5accessibility.com/tests/img-longdesc.html
SF: marked up some spec text for review
MC: preliminary review as sub-group
Longdesc Redux
<richardschwerdtfe> scribe: Rich
<richardschwerdtfe> Subject: Longdesc
<scribe> scribenick: richardschwerdtfe
Steve: we need to be conformant
... we need to be normative
<oedipus>
http://www.html5accessibility.com/tests/img-longdesc.html
Steve: As I said there are minor edits.
The text:
The longdesc attribute may be present, and must contain a valid
non-empty URL potentially surrounded by spaces referencing a
separate document, a content fragment in a separate document or
content fragment within the same document as the image.
Content referenced by the longdesc attribute, if present, must be
exposed by the user agent via a device independent mechanism.The
user must be allowed to make a decision on whether to access the
content referenced by the longdesc.
For example, a user agent may provide access to the document or
document fragment referenced by the longdesc attribute in a context
menu associated with the image. In this case the context menu must
be operable using the keyboard and a visible indication of longdesc
presence must be provided. The option to disable visible indication
and access may be provided via a user preference.
yw
Cynthia: this is too strong
Steve: it is a starting point
More text:
Another example is to provide an indication of the presence of a
description via a programmatically associated visible button or
link. The button associated with the image must be included in the
default tab order of the document. The button may be hidden until an
image is moused over or receives keyboard focus, then user agents
must provide a visual indication and mechanism to access the
associated description. Clicking on the button or pressing a
when the button has focus will navigate to the referenced content or
provide an inline display of the referenced content. Visible
indication and access may be user configurable.
Steve: I provided an inline example using IFrame
Cynthia: I would like to say that the visual indications are MAYs or
SHOULDs
... What is actually required is the way an AT can access it.
John: What we have is ...
Cynthia: I am not convinced that the case for making longdesc
visible is strong enough
Mike: I think it is important that we get it available to the rest
of the working group. Making it discoverable is useful. It is useful
to have these examples.
<Stevef>
http://www.html5accessibility.com/tests/img-longdesc.html
Cynthia: all the examples of visual renderings need to be SHOULDs
and NOT MUSTs
Leonie: Why is it a must for one group of disabilities but not
another
Cynthia: I am not convinced that the example is a strong use case
Steve: Having the provision of content in text form is good for some
users.
John: we do not have data.
... The WhatWg has stated that not having a visual indicator is a
problem
<Zakim> oedipus, you wanted to say that longdesc simulteneous
display for cognative guidance and limited viewport guidance through
image / assistance in interpreting image
oedipus: Did you not find users with a very limited viewport a valid
viewport?
Cynthia: I believed that was hypothetical
<oedipus> no, not hypothetical -- we have extensively courted
feedback on that
Steve: users don't know it would be possible
<oedipus> especiaally in the case of graphs and charts
Roger: It is a valid use case for low vision users who can't see the
whole graph to be exposed to the text
Steve: I put MUSTs in the chart so that we can roll backward. Don't
be overly concerned about that. If the sort of features that we are
talking about here the way we want to go.
... Should we expose URL through the description field in the
accessibility API
correction: Cynthia said that
Steve: The NVDA guys said we should not have to expose this. It
should be exposed via the browser.
<oedipus> i agree with NVDA dudes -- it SHOULD be exposed by the
browser, but (in the words of WCAG 1.0) "until User Agents
support..."
Rich: I am not a big longdesc fan, but my concern is that users with
cognitive impairments will need to see the longdesc text.
Cynthia: not many sites use longdesc
John: ... create more longdescs
<oedipus> cyns, it depends upon your definition of the term "use"
Cynthia: My point is that script can be used by the author to expose
the longdesc
<oedipus> longdesc is there, some mandate it, all want to use it, so
let's get off the fence and support it
Cynthia: this might be better if the author does it
John: I said earlier that I don't think MUST is going to fly but I
would like to see a SHOULD or SHOULD+
... but if this is the problem here is how to fix the problem
<oedipus> easiest fix is to "restore" longdesc -- it doesn't take
any work --unlike removing it
John: the argument we are getting is that there needs to be a way of
describing longdesc info to sigted users
Content referenced by the longdesc attribute, if present, should be
exposed by the user agent via a device independent mechanism.The
user should be allowed to make a decision on whether to access the
content referenced by the longdesc.
For example, a user agent may provide access to the document or
document fragment referenced by the longdesc attribute in a context
menu associated with the image. In this case the context menu should
be operable using the keyboard and a visible indication of longdesc
presence should be provided. The option to disable visible
indication and access may be provided via a user preference.
<oedipus> from what i hear, it sounds as if it conforms to the
verbose desc reqs! <wink>
Another example is to provide an indication of the presence of a
description via a programmatically associated visible button or
link. The button associated with the image must be included in the
default tab order of the document when present. The button may be
hidden until an image is moused over or receives keyboard focus,
then user agents should provide a visual indication and mechanism to
access the associated description. Clicking on the button
pressing a key when the button has focus will navigate to the
referenced content or provide an inline display of the referenced
content. Visible indication and access may be user configurable.
<oedipus> if a user agent is set to receive keyboard focus for
@longdesc, then it MUST add the element for which the @longdesc was
defined to the document's tab navigation order
Steve: where should that go?
<oedipus> it can go at the end, can't it?
<oedipus> thanks steve
<cyns> Another example is to provide an indication of the presence
of a description via a programmatically associated visible button or
link. <ins> when present</ins> The button associated with the image
must be included in the default tab order of the document when
present.
<cyns> Another example is for the browser to add the longdesc to the
accessibiity API such that AT can access it and expose it to users.
<oedipus> need to cover those using AT and those not using AT but
for whom the longdesc would be beneficial
Steve: mouse over may provide a button to click
... I don't have a problem providing an example of how it should
work
Cynthia: I am fine with that but specifying the UI is not our job
MIke: what's next?
Rich: Do you want to put a change proposal in?
... Start writing a change proposal for it
Cynthia: Put this stuff in the change proposal
Steve: I said to Laura we needed a more robust mechanism for this
<oedipus> discoverable versus hidden metadata
<Stevef> oedipus: no problem
<scribe> ACTION: Steve create a change proposal for longdesc that
includes example of how a user agent might render longdesc
information [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action03]
<trackbot> Created ACTION-113 - Create a change proposal for
longdesc that includes example of how a user agent might render
longdesc information [on Steve Faulkner - due 2011-03-26].
<oedipus> rich's wording sounds to me as if it would be more
palatable to the HTML WG
<MikeSmith> http://dev.w3.org/html5/status/issue-status.html
Open Issues
<scribe> scribe: Leonie
<lwatson> scribe, lwatson
<oedipus> scribenick: lwatson
<MikeSmith> regarding issue 31,
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElementSurveyConformace
Choices gives a really good overview of the differences
among the various change proposals
<MichaelC> ACTION: Cynthia to work with Steve and go through
decisions from Lyon and document them regarding HTML-ISSUE-31
[recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action04]
<trackbot> Created ACTION-114 - Work with Steve and go through
decisions from Lyon and document them regarding HTML-ISSUE-31 [on
Cynthia Shelly - due 2011-03-26].
MC: Issue 32, table summary.
CS: Did that get escalated?
MC: It's in the hands of the chairs, so I think there's othing for
us to do now.
... Issue 80, title alternative. In chair's hands.
SF: It's been with them for ages hasn't it?
MC: Issue 92, clean up table.
<oedipus>
http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element
MS: Done.
<oedipus> i have action to comment on poll for ISSUE 122
<MikeSmith> http://dev.w3.org/html5/status/issue-status.html
<oedipus> on behalf of HTML A11y TF
MC: Issue 131, canvas text.
MS: Deadline is 22nd to modify the hange proposal.
s/hange/change/
MS: One thing we should discuss is whether we're happy with this
change proposal.
MC: Was this subitted in a hurry?
RS: We have the bounding rectangle, but it doesn't necessarrily
apply to this.
... We took out references to rich text, so we're not saying "go do
rich text".
MS: If there are no cunter proposals, we need to adopt this.
MC: Issue 133, modal dialogues.
... Do we want this and do we like what's here?
<oedipus> i am proposing the modal dialog for ARIA.next
RS: What we need is a dialogue element that specifies modal.
<oedipus> s/dialogues/dialogs/
MC: Is there anything besides a dialogue that could be modal?
SF: Yes.
RS: I would like to have the use cases enumerated here.
SF: You can have fall back as well. If your JS isn't working for
example.
CS: This is a post last call issue.
<MichaelC> ACTION: Schwerdtfeger to review ISSUE-133 and consider
whether a refined (counter) proposal needs to be submitted [recorded
in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action05]
<trackbot> Created ACTION-115 - Review ISSUE-133 and consider
whether a refined (counter) proposal needs to be submitted [on
Richard Schwerdtfeger - due 2011-03-26].
MC: Issue 124, tab states.
s/124/134/
<oedipus> might be affected by ARIA-in-HTML decision
<oedipus> cooper is correct
MC: this is creating native attribs that are like ARIA attribs.
RS: I don't like tabbing through a tab panel, or tabbing through a
menu.
MC: This is attempting to allow menus to be defined as tablists.
<oedipus> borrowing concepts from ARIA for HTML5 -- might be OBE by
ARIA-in-HTML decision
MC: So we support the change proposal.
RS: Give me an action to review this one.
SF: If something has a modal attrib, it's default role could be
dialogue.
<oedipus> s/default role could be dialogue./default role could be
dialog/
SF: We should have a discussion as to whether it should be an
element or an attribute.
<MichaelC> ACTION: schwerdtfeger to review ISSUE-134 [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action06]
<trackbot> Created ACTION-116 - Review ISSUE-134 [on Richard
Schwerdtfeger - due 2011-03-26].
MC: MC: Issue 135, link canvas spec.
... Looks like there has been a call for consensus amongst the
chairs on this.
... Issue 142, poster alt.
JF: The poll closed, and we have two change proposals.
... It's waiting for the chairs.
<oedipus>
http://www.w3.org/2002/09/wbs/40318/issue-142-objection-poll/results
MC: Issue 144, underlining <u>
CS: No harm to make it conforming.
<oedipus> presentational elements should be only conforming with a
warning -- USE CSS!!!
s/underlining/conforming/
MC: Issue 147, playback rate undefined.
JF: Doesn't affect us much.
MS: We should get Sylvia's input on this.
MC: Issue 153, link external.
... Issue 155, cell border.
MS: I've read through this but not sure I fully understand it.
CS: Don't think it's an accessibility issue.
MC: Issue 161, accessibility API mapping.
CS: We need to do some work there.
SF: It's just to add a link in there.
MC: Issue 163, navigating tracks
JF: We're discussing this tomorrow.
MC: The bug triage sub team hasn't seen any bugs it needs to take a
look at.
<oedipus> i am in contact with others in w3c about bugzilla 4.0 a11y
improvements and those that still need to be logged on bugzilla's
bugzilla
<oedipus>
http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs
MC: There are five bugs...
... 10249, canvas requires a content selection method, assigned to
RS.
... It needs expanding, or closed.
<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10249
<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10896
MC: 10896, enable device independent access to event handlers, filed
by LW.
<oedipus> hixie said that he thought it more appropriate for the DOM
/ WebApps / WebEvents group for DI access to event handlers
<oedipus>
http://www.w3.org/WAI/PF/HTML/wiki/Access/event_handler_requirements
MC: 11328, canvas authors need to be able to assess pixel
resolution, filed by RS.
CS: Assign it to Doug, he should be able to find someone to look at
it.
MC: 11329, HTML5 supporting browsers must support resize event
during zoom, filed by RS.
... It's been assigned to Web Apps WG, is that the right place?
JF: Is this a TF concern?
CS: Yes, it relates to zoom.
MC: 11391, provide examples of track usage, filed by FO.
MS: This would make the track element usable for additional audio
tracks.
JF: So this is related back to issue 152.
... Think I may have reported this back to Martin a couple of weeks
ago.
... Think I may have reported this back to Martin a couple of weeks
ago.?
MC: So here's nothing else to do on this right now?
<oedipus> we could look at
http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs
<MichaelC> ACTION: foliot to raise Bug 11391 with media sub-team
[recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action07]
<trackbot> Created ACTION-117 - Raise Bug 11391 with media sub-team
[on John Foliot - due 2011-03-26].
MC: We needed to do a review of the whole spec, but this could be a
PF action as opposed to a TF action.
... The idea was to start writing WCAG techniques as a mechanism for
discovery.
... Nothing for us to do on spec review right now.
MS: It looks as though we don't have any outstanding actions on
drag/drop anymore.
SF: Gez and Everett looked at the spec and seemed not to have furter
concerns.
RS: What happens if ARIA is used with respect to HTML5 drag/drop?
Could we ask Gez to look into this?
<MichaelC> ACTION: Lemon to review if HTML drag and drop model
conflicts with ARIA drag and drop model [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action08]
<trackbot> Created ACTION-118 - Review if HTML drag and drop model
conflicts with ARIA drag and drop model [on Gez Lemon - due
2011-03-27].
<oedipus> [ADJOURNED]
MS: Meeting adjourned.
Summary of Action Items
[NEW] ACTION: Cooper - take SteveF's Lexical Processing prose, add
definition of @role, and propose as change proposal [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action02]
[NEW] ACTION: Cynthia to work with Steve and go through decisions
from Lyon and document them regarding HTML-ISSUE-31 [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action04]
[NEW] ACTION: foliot to raise Bug 11391 with media sub-team
[recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action07]
[NEW] ACTION: Gregory - submit comments on behalf of TF to
http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/ -
due 2011-03-24 [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action01]
[NEW] ACTION: Lemon to review if HTML drag and drop model conflicts
with ARIA drag and drop model [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action08]
[NEW] ACTION: Schwerdtfeger to review ISSUE-133 and consider whether
a refined (counter) proposal needs to be submitted [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action05]
[NEW] ACTION: schwerdtfeger to review ISSUE-134 [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action06]
[NEW] ACTION: Steve create a change proposal for longdesc that
includes example of how a user agent might render longdesc
information [recorded in
http://www.w3.org/2011/03/19-html-a11y-minutes.html#action03]
[End of minutes]
_________________________________________________________
Received on Sunday, 20 March 2011 00:21:47 UTC