HTML Accessibility Task Force Teleconference -- 22 Feb 2010

<trackbot> Date: 22 February 2010

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0179.html

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0178.html

<oedipus> RS: We would introduce an @adom attribute, it can be called something else

<oedipus> RS: If the sub tree content is for accessibility then the @adom marker tells the AT that it is for accessibility and browsers can also map the content to the accessibility API

<jcraig> scribe: jongunderson

<oedipus> RS: We have a problem with WCAG 2 for browsers that don't support canvas

<oedipus> RS: I tried incorporating DB content

<oedipus> RS is reading the proposal ....

<oedipus> RS: DB you asked about synchronization of @adom with canvas

<oedipus> RS reading the synchronization definition....

<oedipus> RS: Colors and zoom has no standard way to define

RS: I want to rasie the point from last friday, if the @adom is set to false, and then would be equally inaccessible
... This is tru, but if the author wants to be accessible it allows them to mark the information as accessible and comply with WCAG
... Do we want to stay with the @adom proposal?
... We need to put up a straw poll today to take it to the meeting on Thursday

JC: I don;t think that was my exact requirements
... The issue is that several of us don't think we need the attribute
... By adding the attribute and making it false by default, there could be some accessible content that will not be marked as much
... The one exception is the message "Get a better browser", but if they do provide alternative or accessible content why do we need the marker

FO: Adding attributes by the author allows accessibility checkers to do some level of accessibility, I support the @adom attribute, I don't think it is alot of work

RS: I agree with it too
... The fall back content may be accessible, but it may not represent what is on the canvas

<Zakim> jcraig, you wanted to respond to franks point: existing canvas content is irrelevant, b/c there is no current way to make it accessible

RS: The question is does it map to what the user using the canvas is seeing and doing

<oedipus> plus 1 to jcraig

JC: We have not see much canvas content is not a reason why we need the @adom attribute
... We should not be hung up on the fact it is not accessible yet

RS: The point is that we can make it accessible, it comes down what is being mapped to what is being drawn
... The alternative rendering maybe accessible we just don't know
... This is how authors have been using fall back content
... I would like to hear form other people in the group
... DB

DB: This is the wrong time
... I would just mention, you could make canvas accessible, but it is very difficult, these approaches are also difficult
... I was agreeing with FO, but I am also see JC point of view, I am not optimistic about accessible content

<richardschwerdtfe> scribe: rich

<richardschwerdtfe> jon: I think we need a marker

<richardschwerdtfe> Jon: there is not guarantee what that sub content is going to be

<oedipus> scribe: jongunderson

<oedipus> JRG: would never see canvas?

RS: It has been generally agreed if an author wants an alternative rednering would replace canvas
... basically the sub I'll be right back , battery died
... A test group can say what do you got in there
... Rule sets will be same as being developed with the OOA, there would be manual tests

JG: OK

<Zakim> jcraig, you wanted to address the argument that the @adom marker will reflect author intention

<oedipus> accessible rendering of content, not canvas - if canvas contains interactive elements, must be made interactive even if canvas support turned off or not supported

JC: This @adom tag would be a marker doesn't really matter to the user, if this part of HTML 5 the authoring tools will add it by default and not really work as a marker

<frankolivier> q

JC: If we can's trust authors to make accessible content, then the attribute can also be abused
... Who is the marker for test tools or AT?

RS: What @adom does is say to map the sub content to the accessibility API

JC: We think all the content should be mapped to the accessibility API, why hold it back?

<Zakim> oedipus, you wanted to ask if we are drawing a distinction between access to content in canvas and access to canvas?

FO: I want to draw a parallel with ALT text for image, you have conformance checkers to look for ALT text
... @adom is kind of like ALT attribute for image

JC: In both cases, this is the descendant conent of the sub tree

RS: The sub content is back up content, when the canvas content cannot be rendered
... When you want to say this content is mapped to the accessibility object tree like the controls in any GUI
... If you were to sit next to a sighted person the sub tree content should represent the sub tree content

<Zakim> jcraig, you wanted to ask frank to clarify his comment regarding img:alt :: canvas:adom

RS: If you don't set the @adom attribute the user just gets the fall back content

JC: One of the things I want to clarify the point, the sub content would only be accessible if the authors add this attribute, I propose it should always be mapped
... I would like clarification of the ALT text analogy

<oedipus> agree with JC

FO: If you are using an accessibility compliance checker could check to see if the author did anything to make the canvas accessible, just like it ALT attribute is missing from an image
... If ALT text had two purposes the complaince checker couldn't figure out was done

JC: A compliance checker couldn't determine if the canvas needed accessible content, it could be decorative

FO: The author then could indicate that in the sub tree content, it could say that

JC: You can also set the ALT="" just because you are lazy

FO: Some form of indicator is useful for the author to provide some information

JC: This is saying to me that the ALT text is on the page ....

RS: I don't think we are forcing the user to do anything, we are providing a way for the author to provide intent

JC: You are telling the assistive technology and the browser not to expose content unless this attribute is added

RS: Are you saying the default value is TRUE

JC: I am saying that the value should always be true
... Why does the user care if it an exact replica or an alternative

RS: The user cares about equal functionality
... The keyboard and the accessibility information is the same as the able bodies person sitting next to them
... Sure people can create accessible content but it provide a means to render the alternative ...

JC: What you are also saying is the focus model needs to change, this @adom flag would provide the information to ...

RS: The author would need to provide a means to render the sub content ..

JC: You mean the user agent, or the author needs to provide button

RS: Yes

JC: That sounds like a 2010 D-Link

RS: I am not making any claims, I don't know what the sub tree content is, it is just there, what do I do with it?
... We have debated this for 40 minutes, do people want to submit to the proposal to a straw pole for submission to the HTML working group

<oedipus> jcraig, reminds me of details "button" child problem

<richardschwerdtfe> Proposal: Should we take the adom attribute proposal to straw vote to take it to the HTML working group?

<jcraig> -1

<richardschwerdtfe> +1

<frankolivier> +1

<oedipus> abstain

<davidb> +1

<oedipus> jcraig, check http://www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010

<oedipus> fine with vote

We will take it to a straw vote in the task force, do we want to change to the text?

RS: Is there anything other than disagreement

<oedipus> rich, can you post the finalized text to the list or point to it after the meeting?

JC: The author must requirements are specific to the attribute value, they should be there regardless of the attribute

<richardschwerdtfe> The canvas element has a third boolean attribute, 4adom, to indicate if the canvas subtree is an accessible DOM sub-tree representation of what is drawn on 12file:///Users/richardschwerdtfeger/Downloads/the-canvas-element. If it is true, standard HTML elements may be used in the 12file:///Users/richardschwerdtfeger/Downloads/the-canvas-element sub-tree, however the rendering of the subtree is controlled by script through the canvas API. Wh

<richardschwerdtfe> 12adom is set to "true" the elements within the 12file:///Users/richardschwerdtfeger/Downloads/the-canvas-element MUST be rendered transparently to ensure inclusion in the HTML keyboard navigation order without effecting the visible rendering of the web page. When adom is set to "true" the 12file:///Users/richardschwerdtfeger/Downloads/the-canvas-element the must be synchronized with the canvas rendering. The default value for 12adom is

<richardschwerdtfe> false to indicate that the canvas subtree is only used as fallback content and may not be used as an accessible DOM subtree representation of what is drawn on 12file:///Users/richardschwerdtfeger/Downloads/the-canvas-element. Authors supporting an accessible 12adom sub-tree:

<richardschwerdtfe> • MUST synchronize the accessible sub-tree elements, semantics, and structure with the canvas rendering.

<richardschwerdtfe> • MUST render and maintain visible focus of the 12file:///Users/richardschwerdtfeger/Downloads/the-canvas-element subtree element on the rendered 12file:///Users/richardschwerdtfeger/Downloads/the-canvas-element

<richardschwerdtfe> • MUST render and maintain the keyboard caret insertion cursor of the canvas subtree element on the rendered 12file:///Users/richardschwerdtfeger/Downloads/the-canvas-element

<richardschwerdtfe> • SHOULD ensure that the 12file:///Users/richardschwerdtfeger/Downloads/the-canvas-element rendering reflects the user settings for font, color, and zoom

RS: If it sets it rue ...

JC: I think those requirements should be , I guess in relation with this proposal its ok
... The last one authors should ensure, is completely separate from the @adom attribute

RS: I will change that
... Anything else?
... DB did I meet your concerns about synchronization?

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/att-0178/canvaselement-issue74

DB: The link is not working for me, there we go..
... There is not alot of content here
... I guess it is fine

RS: I have made JC change

RSL I am going to change this to ..., author should insure that the author setting os font, color and zoom regardless wether ADOM is set to be true

RS: I will send to MC after the meeting
... The next thing

CARET Trakcing Issue 19

RS: Has SF make any progress on caret tracking, he is not here though to day
... I will send this to MC to set up a straw vote

<oedipus> rich, your data dump into IRC came out very confused in minutes

- DRAFT -

HTML Accessibility Task Force Teleconference

22 Feb 2010

Attendees

Contents

CARET Trakcing Issue 19

Summary of Action Items

Scribe.perl diagnostic output