HTML Accessibility Task Force Teleconference -- 28 Jul 2011

<trackbot> Date: 28 July 2011

<Joshue> Hi Janina

<janina> Meeting: HTML-A11Y telecon

<janina> Scribe: Marco_Ranon

<janina> Scribe: John_Foliot

<janina> Scribe: Cynthia Shelly

<janina> Scribe: Michael_Cooper

<janina> agenda: this

Last Call Bug Review http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review

<JF> scribe: JF

<janina> OK

JS: we should start by going through the wiki issue by issue

<janina> Greg, We're about to figure out how to proceed. Certain people have particular knowledge/concerns.

JS: we have a lot to go through

how to proceed through the reviews in house to date - we have a fair bit of content already

we also have people who will be coming and going on this call

JS: given this, not sure how to proceed due to people coming and going - suggest we just go through sequentially from top to bottom
... Greg has submitted a lot of content - "camera ready" bugs

Greg is on the IRC, wonders if there are any other comments that were not included in the wiki

KF: If Greg is on the phone please speak up

some of the content might not have made it to the wiki - it only went to the UAAG list and janina

MC: if it was only added to UAAG wqiki yesterday it may not have been noted
... as a note, at the top of the wiki there is a full page review of the wiki content available at: http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/All

same content as in the wiki

[working on having Greg's submissions sent to the TF mailing list

<Joshue> Go Léonie :-)

JS: for the record, Leonie has agreed to chair the bug triage sub-team, which will have a fair bit of work after today's call

shepharding these bugs through the process

JS: doesn't mean she will be doing all the work, but rather will direct to others with specific expertese

<janina> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review

JS: Looking at the wiki, it is our intent to work through this wiki today, to decide what we need/want to escalate to the bugzilla

suggest that unless we have a particular reason to skip around, perhaps we should start at the top

however if the UAAG folk (who have joined us today) need to leave early, we could also start with their submissions first

as we go through this, and assign bugs-to-be-filed to various individuals, they should file the bug and then add the URI of that bug into the wiki'

KF: does the wiki also contain all the links of other issues of concern?

is this the definitive source of issues of concern?

JS: the only reason to be hesitant is that the wiki might not have a complete listing of issues we have already raised (i.e. @longdesc)

<kford> JS says wiki pretty solid excluding issues where reconsideration may be needed.

this is a good representation of the issues we have been working on, but some details may not be fully captured

Alls aid however, this is probably the best resource - how complete however is unknown

Michael Cooper (for example) has copied over all of the UAAG wiki comments to this wiki as well

<Joshue> http://www.w3.org/TR/2011/WD-html5-20110525/scripting-1.html#scripting-1

<Joshue> Janina, I just put the link to the scripting part of the spec in IRC

<Joshue> Cyns, good feedback on Forms btw

JS: Can we ask someone to review the comments we have on Structure - provide a summary from the wiki page

<Marco_Ranon> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/All#Structure

<Joshue> No bugs on structure?

MC: Simon notes that it looks fine, made some comments about accessibility semantics

MCL James Craig asked about print-formatted file issues

JS: Seems that these are not really items we can file as bugs - we should monitor them but not much more we can do at this time

MS: asks Greg to summarize his comments

[Greg has supplied a couple of use-cases and proposed replacement language]

will paste into irc now

<Greg> Here's email I sent:

<Greg> Hi! The following has been added to the wiki at http://www.w3.org/WAI/UA/work/wiki/HTML5_review_by_UAWG_notes#Non-Interactive_User_Agents:

<Greg> Non-Interactive User Agents

<Greg> The current draft HTML5 spec says:

<Greg> Non-interactive presentation user agents

<Greg> User agents that process HTML and XHTML documents purely to render non-interactive versions of them must comply to the same conformance criteria as Web browsers, except that they are exempt from requirements regarding user interaction.

<Greg> Typical examples of non-interactive presentation user agents are printers (static UAs) and overhead displays (dynamic UAs). It is expected that most static non-interactive presentation user agents will also opt to lack scripting support.

<Greg> A non-interactive but dynamic presentation UA would still execute scripts, allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus" is irrelevant when the user cannot interact with the document, the UA would not need to support any of the focus-related DOM APIs.

<Greg> It is very important that developers should not relegate user agents to the "non-interactive" category if there is benefit to the user in being able to interact with them.

<Greg> Use case: Imelda uses a screen enlarger. She runs an application that displays a static, web-based slide detailing today's weather forecast. Imelda uses a screen enlarger, and normally reads blocks of text by having the magnifier track the text caret as she moves it through the content. However, as the developers considered theirs a non-interactive user agent, they left out the ability to do...

<Greg> ...caret browsing. With luck, the screen enlarger will be able to access the application's DOM and determine the screen coordinates of each word, but it would certainly be easier if the application supported caret browsing.

<Greg> Use case: The weather application that Imelda is running allows the user to select text with the mouse and automatically copies that text to the clipboard. However, the developers did not consider this "focus" or "activation", or even "selection" because the selection does not persist and the user can't perform their choice of actions on it. However, by this decision they are making...

<Greg> ...functionality available to only one input modality, and users who rely on other modalities such as keyboard or speech recognition are denied full access. In this case, the developers should not have considered their application non-interactive, and instead implemented full focus and selection functionality.

<Greg> Recommendation: The HTML5 spec should include wording that clarifies that user agents should not consider themselves non-interactive if they render content to the user on any system that can take input, and more specifically should not omit support for focus-related DOM APIs just because they do not expect to be taking input. Ideally it would include use cases similar to the above in order...

<Greg> ...to help readers understand the issue.

<Joshue> nope

<Joshue> that is, I don't disagree

JS: Looks like this could be filed as-is

<Joshue> http://www.w3.org/Bugs/Public/

<Joshue> HTH

http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG&component=HTML5%20spec%20%28editor:%20Ian%20Hickson%29&priority=P3

[setting up Greg to file his bugs directly to bugzilla]

[Michael cooper updating wiki to reflect fact that Greg will file his own bugs]

KF" James Craig points out a few things

some are not really actionable, while others (such as awkward wording) could be actionable

Greg: James first point overlaps with one of the comments i submitted

MC: as we review this, some items are actionable and smoe are not

will add a note to the bottom that Greg Lowney is filing a bug that encompasses James' first point

JS: can someone else take on the task of filing the other bugs?

KF: can take the others
... will file bugs - even the low priority ones as once in the system...

<Joshue> JF: Embed is legacy and object is more recent.

<Joshue> JF: I'll take it

JF will file a bug on Jame's comment re: 2.2.3. Extensibility and embed vs. object

<Joshue> JF: Seems we should push back on CSS Wg

MC: wonders if we should be pushing back on the Systems Colors issue at the HTML WG since CSS WG have not responded

JS: seems that we should file a bug on this

<Joshue> JF: Thats an easy bug, I'll take it

JS: Notes that Rich is now n the call, and mindful that he cannot be here for the whole call suggest we move to the sections that Rich looked at

<janina> http://www.w3.org/TR/2011/WD-html5-20110525/editing.html#contenteditable

<Joshue> Rich has 9 bugs

http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Editing

<Joshue> http://www.w3.org/TR/2011/WD-html5-20110525/editing.html#contenteditable

<Marco_Ranon> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/All#Editing

<Joshue> 7.5

RS: the general problem is that the editing section is called the contenteditable section

when you go into that section you start talking about contenteditable and then it jumps to design mode

what is not clear is the support between design mode and keyboard editable

design mode makes the whole section editable, while contenteditable is by section

it is mostly editorial

one of the other issues is that different browsers have different keyboard navigation

CS: The WG has pushed back fairly hard on specifying uA behaviors

wonders if a comment that notes "follow platform conventions" would be sufficient

JS: sounds like a clear bug

RS: that sounds fine to me. for example, the Mac does not have an insert key, but on the same platform it should be consistent

GL: notes that regardless of what happens in HTML5 that this should be addressed in the UAAG stack as well

JS: I think this distills down to being consistent at a platform level

<Joshue> sounds good

[all agree this should be a bug]

RS: agrees to file this as a bug

(and previous item as well "Title for Section")

RS: the problem appears that design mode looks like it was added after the fact

so these issues all seem to be based on that editorial change, however Rich will file 3 bugs based on this

<Joshue> JF, I'll scribe for a bit

<Joshue> Scribe, Joshue

<Joshue> Scribe: Joshue

MC: The wiki page for edits is above
... I can make edits now..
... We are filing a bug for each of his headings

JS: Please add the keywords a11ytf

RS: Ok

MC: We have other comments from Greg that I included.

Greg: Meaning rather than presentation is important to screen readers etc
... I have some example solutions, do people agree?

JS: Comments?

CS: Sounds like a big bug
... Are we asking them to add elements?

Greg: I proposed atts to the mark element.

CS: Maybe less of a fight.

Greg: Should something else be used?

CS: Should we create a bug, but not have a specific edit?

JS: That would be acceptable.
... If we see an issue, file the bug - even if solution is not in hand.
... It keeps it on the table.
... Any objections?
... Yes Greg, please do
... We are noting it in wiki

Greg: Anyone who can give advice on this, new att to be used in this context please let me know.
... Eg the meaning and flag att
... Not sure yet

<Greg> E.g. where I suggested a new "meaning" attribute, should we reuse the "title" attribute?

JS: Contenteditable is updated in the wiki, going back to the sequence.

Greg: Is that it from Rich?

RS: Not from me
... I am really busy with canvas.

JS: Going back to Globals.

<Marco_Ranon> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/All#Globals

JS: Break?

Scribe is on standby

SUBJECT: Globals

http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Globals

Comments etc above

Elements http://www.w3.org/TR/2011/WD-html5-20110525/elements.html#elements

Content Models http://www.w3.org/TR/2011/WD-html5-20110525/content-models.html#content-models

The doc that we file bugs against is the HTML Spec (Editor:Ian Hickson)

JF: P3 (as a level of urgency will suffice)

JS: Yes

JF: The important thing is to capture the bug numbers etc so we can see them thru.

JS: We have noted who has taken the bugs on, if everyone can annotate them with the URI that would be great
... Looking at Globals
... Summary from anyone.

JF: Simon noted these are UAAG issues etc,

JS: Greg should file his comments, Simons comments are picked up in his bug.

JF: Gregory Rosmaita was doing work on AccessKey etc,
... I have a lot to do and don't want to take too much on,
... AccessKey should be revisited, Gregory did a lot of work

JS: More on Simons comments?

JF: A typo etc

JS: File a bug anyone?

Greg: Is that relating to contenteditable?

CS: A WAI issue, not a HTML bug

Greg: It seems reasonable to me (Simons suggestion)

CS: We need to talk about that.

JF: I second Gregs idea

JS: We'll leave it as discuss, put it on the PF agenda

JF: To continue, Simon notes Global att hidden - it should be up to AT. Should it be rendered if in the DOM?

CS: Don't agree

JS: Is this a UAAG discuss?

JF: Yeah

JS: Lets point it to UAAG

JF: Any comments on the rest of Simons issues?

Group: Seems right.

Re:Tabindex

the title att is a UAAG issue

CS: Deadline next Weds, midnight Boston.

JS: Moving on

Simon notes 'Content Models' looks fine

<JF> scribe: JF

Josh:

1 think that is a missed opportunity to reinforce semantics for assistive technology

proposed some sample spec text to address thta

seems to be a recurring theme in the spec - that it often misses the opportunity to highlight the benefits of semantics to users of AT

CS: agree that is a good idea - if done carefully it would likely be embraced

[Josh reading out his proposed text found in the wiki]

GL: 2 thoughts

<Joshue> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Globals#3.2_Elements_.5B1.5D

there are times when being conforming is less important than ensuring accessibility - for example if an author uses a non-conforming code (eg. @longdesc) how terrible is it?

perhaps setting a flag that notes that a series of changes conformant content that will emerge at the end of interaction conformant, but may fall "out of conformance" during the process

JS: do we want what is suggested here filed at this time

or discuss further

GL: since it is non-normative, i don't see an issue with filing that

Josh: will file this as a bug then

GL: should we discuss the idea of a flag for batch actions that move from conformant to non-conformant to conformant again?

CS: file the bug, but be prepared for a lengthy discussion on that idea

JO: happy to file this as a bug, as-is and then go from there

Next looked at content models

mostly good, however there was some issues around SVG and a11y

the SVG example(s0 in the spec should be fully accessible

Josh thinking of pinging Doug or Chaals about this

Josh will file another bug here

JO: issue with metadata being "out of band" - confused, what does this mean?

Does this relate to @summary?

JO: the definition of what Fallback content is needs to be made clear - this is a recurring "discussion" that has surfaced often

<Joshue> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8885

this resolves to an existing bug (just referenced by Josh)

JS: doesnt sound like there is a bug her to file - is there an action we need to take?

<richardschwerdtfe> gotta run

JO: suggest that we might need to resurrect bug 8885 at this time

JS: sounds like we're covered

<Marco_Ranon> SCRIBE: Marco_Ranon

<Joshue> thanks Marco

<Joshue> I'm going to step off for a bit, can someone please ping me on IRC when table is coming up?

JF: want to flag that metadata needs to be discussed further

<Joshue> thanks JF

[discussion about editing wiki]

MC: Josh to file bug re 3.2 Elements, followed by further discussion

JS: JOC to file bug on SVG example

JS no action on device independent events

Metadata Content/ Other notes: further discussion

Linked to bug 8885

s/Metadata Content/ Other notes/Fallback content

Metadata Content: further discussion

MC: Gregs reccommendations

GL: those are use cases for an author element
... there is a lack of ways to identify an author

JF: probably the group will say that maybe this could be done with microdata/microformats

JS: to be discussed

GL: what is the decision on the two decisions: using keywords or author?
... i don't thing microdata/microformats would address the issue

JF: probably keyboard is a good reccommendation, but author is microformats
... we can discuss this and file a bug if we think it necessary

MC: add 'for discussion' to the wiki
... JF to follow up on both
... Next is ARIA

http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/ARIA

MC: Joseph Scheuhammer's comments
... general comment, to be discussed
... First table: 1. menu: Why isn't the implicit ARIA role "menu"?

JS: ARIA call should discuss this

MC: ARIA call on Monday, then report to the team

CS: Joseph and Steve Faulkner on vacation
... we can try to answer now

MC: aria role search - applies to a section, not the element

<MichaelC> ACTION: Rich to write whitepaper on ARIA features that seem similar to HTML features but aren't [recorded in http://www.w3.org/2011/07/28-html-a11y-minutes.html#action01]

<trackbot> Created ACTION-131 - Write whitepaper on ARIA features that seem similar to HTML features but aren't [on Richard Schwerdtfeger - due 2011-08-04].

<MichaelC> action-131: we might assign this to someone else, just putting in the tracker for now

<trackbot> ACTION-131 Write whitepaper on ARIA features that seem similar to HTML features but aren't notes added

MC: input type time ect, Why isn't their implicit role "textbox"?

CS: there is no appropriate ARIA role for that

<MichaelC> action-131: questions raised in Joseph's review for LC are the sort of things it would be good to explain http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Spec_Review/ARIA

<trackbot> ACTION-131 Write whitepaper on ARIA features that seem similar to HTML features but aren't notes added

<JF> +Q

Second table: CS answering to all questions, all answers will be in the wiki and will be addressed in the new action 131

JF: i'm working on a note about aria describedby

CS: will it go in this section?

JF: it impacts a lot of things

Next: Insert

http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Insert

CS: something might be actionable
... 3.5.1 log a bug against the mapping document
... 3.5.3 same as above
... not sure that's true, who should we ask to?

JS: maybe RS or SF?

CS: look for someone to confirm before we file a bug, and see if iot should be addressed as part of WCAG2 techniques
... 3.5.5 and 3.5.6: are those really problems?

JS: ask David Bolter

CS: mutation events, it would be good to ask AT vendors about this
... too weak to opena bug
... open a bug anyway and look for more information
... HTML 5 WCAG 2.0 techniques, it would be good to have some

MC: there is something in the techniques wiki, but we raise an agenda item to discuss this further in wcag WG

JS: short break - 5 minutes

<Laura> Have to go now. Bye.

<kford> Scribe: KFord

<Marco_Ranon> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Block

<JAllan> 4.5.3. The pre element

<JAllan> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Block

Group starting with comments on pre element.

MC reading comments from Wiki.

JF: A bug has already been filed.

Task force agrees with bug.

Second comment was around div.

No objections to this being a TF comment.

No comments on inline.

Embeds, canvas and media have no comments that made it to the wiki.

JF will be filing media bugs later today.

<janina> Media minutes at http://lists.w3.org/Archives/Public/public-html-a11y/2011Jul/0136.html

Imagemaps are next. MC did a review.

MC: I had no accessibility issues on the map element

MC going over comments on area.

CS: Area doesn't sound right at all. Each area needs alt.

MC: It explains later that user agents should sort out duplication.

Group doesn't think this is right and that UA shouldn't have to sort this out. MC filing bugs.

Now on image map.

Group talking about relative sizing of images and such as outlined in MC comments.

MC asks about what happens with browser zoom.

MC: It does seem like some clarification is needed.

CS: Also a line on what happens with browser zoom.

MC filing bugs. See wiki comments.

Now moving to section on math.

John Gardener did a areview.

CS: I had people from MS look at this and we think the issues are implementation not in the spec.

Group now sorting out if math element has correct mappings in other specs.

CS thinks a bug might have been filed already or that this was discussed.

MC: SteveF filed 10438 which was resolved as won't fix.

JS: I think we need a bug.

JS will ask John to file bug so this comes as public feedback.

Group now talking about alt text on the math element.

MC: Spec says the details of how mathml are defined in the appropriate specs.

Now looking at SVG.

Comments again from John Gardener.

JS will ask John to file bug on his comment about talking about image role.

Now talking about alt text and title.

Janina will need to follow up with John to get issues filed and determine if these go to SVG or HTML5.

See MC wiki comments for full details.

Now moving to tables.

<JAllan> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Tables

Group sorting out whether to talk about JO comments on summary.

JO: The examples are not overly accessible, in particular the way they work with screen readers.
... The examples don't work well today.
... I used these experiences as as the foundation for my change proposal.

JF: There was a question between the author spec and the full spec about the attributes scope could take.

<JF> @scope bug filed here: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13331

JS: Thanks to JO for getting a great talbe change proposal together.

JO: I'd like to talk about the change proposal if we could.
... I'm trying to give this loads of energy but am quite happen to open source this to my friends and colleagues.

<Joshue> CP http://www.w3.org/WAI/PF/HTML/wiki/Category:Table_Summary#Extending_.40summary.3F

MC: Three other people submitted comments so we should look.

Beleive issue of tables being created without caption caught up in change proposal.

MC entering bug details for one of the examples. See wiki.

Group now looking at SH comments.

Relative to layout tables, TF feels they have achieved the balance needed with role=presentation and still allowing good compat story.

<Greg> My comment "Reading and navigation order" discusses tables. 25.1.2.4 Reading and navigation order - http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/All#Reading_and_navigation_order

<Greg> Authors should be able to specify preferred direction and/or order for sequential navigation, even among things such as tables that would not normally have a tab order.

<Greg> * Use case: Masahiko is reading a web page, and uses browser commands to move the text cursor to the next and previous paragraphs. In most cases this works fine because the suggested reading order is that in which elements occur in the HTML. However, when Masahiko encounters a table that is designed to be read down the columns rather than across the rows, this simplistic navigation is...

<Greg> ...entirely inappropriate. A similar problem occurs when CSS is used to rearrange blocks of text on the screen.

<Greg> * Recommendation: Allow marking up a table to indicate whether the preferred reading order is by columns, by rows, both, or neither. This could be done with a new attribute, such as orientation="columns".

Group indicating GL idea sounding like new feature. Suspect it is too late for feature in HTML 5 but still want to file as a bug.

Expect it will get moved to the next version of HTML.

Group now talking about opportunities to get issues raised and when.

MC: Anyone can file an individual bug. Just don't put a11ytf on those bugs because a11ytf indicates task force approval.

CS: We should be careful about asking for new features without having compelling evidence.

JB: There is not agreement on whether that the HTML 5 spec is feature complete.

CS: I'm just saying that if we know something is going to controversial we should have a better case.

Group again revisits concept that anyone can file a bug.

Group now working on schedule because task won't be finished today.

Group sorting out scheduling times.

MC likes 7A eastern.

Group laughs.

Group settling on 8A Pacific as a starting time on 8/1. Same time as today's meeting.

MC: If you file a bug, please update wiki on the line where you are listed to file a bug.

JB: I was looking at a lot of bugs coming to the list and see a lot of good bugs. I appreciate the work.

<MichaelC> http://www.w3.org/WAI/PF/HTML/wiki/Process_to_submit_HTML_spec_comments

<MichaelC> http://www.w3.org/WAI/PF/HTML/wiki/Bugs

Group going over bug filing and resources.

Group jumping to the details element.

MC: I looked at this.

MC goes over his wiki comments.

JS: There was a time we thought details should be expanded to include the longdesc case.

MC: We can think of use cases that this element can meet. Do we want to pursue this path or others.

CS: I like the details element.
... We often use more info on our pages and this is tough. I think details would be helpful in this case.
... If this was done well, supported keyboard access and such I think this would be good.

GL: I don't want to overload this.

JS: The question is now do we think this is clear enough.

MC: I will file a bug suggest examples that demonstrate use cases on details.

- DRAFT -

HTML Accessibility Task Force Teleconference

28 Jul 2011

Attendees

Contents

Last Call Bug Review http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review

Summary of Action Items

Scribe.perl diagnostic output