See also: IRC log
<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
<JF> scribe: JF
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
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> 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
<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> that is, I don't disagree
JS: Looks like this could be filed as-is
[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
<Joshue> Rich has 9 bugs
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
... I can make edits now..
... We are filing a bug for each of his headings
JS: Please add the keywords a11ytf
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?
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
... 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
... 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.
Scribe is on standby
Comments etc above
<discussion on various spec related docs>
The doc that we file bugs against is the HTML Spec (Editor:Ian Hickson)
JF: P3 (as a level of urgency will suffice)
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?
JS: Lets point it to UAAG
JF: Any comments on the rest of Simons issues?
Group: Seems right.
the title att is a UAAG issue
CS: Deadline next Weds, midnight Boston.
<discussion on deadline etc>
JS: Moving on
Simon notes 'Content Models' looks fine
<JF> scribe: JF
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
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
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
... 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
... JF to follow up on both
... Next is ARIA
MC: Joseph Scheuhammer's
... 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
... 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
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
CS: something might be
... 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
<JAllan> 4.5.3. The pre element
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.
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
... 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.
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. 188.8.131.52 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 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.
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
... 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.
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/P3/JF:P3/ WARNING: Bad s/// command: s/Metadata Content/ Other notes/Fallback content Succeeded: s/not 100% agreement on the fact/not agreement on whether/ Succeeded: s/revisists/revisits/ Found Scribe: Marco_Ranon Found Scribe: John_Foliot Found Scribe: Cynthia Shelly Found Scribe: Michael_Cooper Found Scribe: JF Inferring ScribeNick: JF Found Scribe: Joshue Inferring ScribeNick: Joshue Found Scribe: JF Inferring ScribeNick: JF Found Scribe: Marco_Ranon Inferring ScribeNick: Marco_Ranon Found Scribe: KFord Inferring ScribeNick: kford Scribes: Marco_Ranon, John_Foliot, Cynthia Shelly, Michael_Cooper, JF, Joshue, KFord ScribeNicks: JF, Joshue, Marco_Ranon, kford WARNING: Replacing list of attendees. Old list: Janina +1.650.468.aaaa Marco_Ranon JF Michael_Cooper Kelly_Ford Cooper cyns Joshue +1.425.895.aabb Greg Léonie_Watson Rich_Schwerdtfeger Leonie Jim_Allan Laura_Carlson +1.617.325.aacc KimPatch Judy New list: Janina +1.650.468.aaaa Marco_Ranon JF Michael_Cooper Kelly_Ford Cooper cyns Joshue +1.425.895.aabb Greg Léonie_Watson Default Present: Janina, +1.650.468.aaaa, Marco_Ranon, JF, Michael_Cooper, Kelly_Ford, Cooper, cyns, Joshue, +1.425.895.aabb, Greg, Léonie_Watson Present: Janina +1.650.468.aaaa Marco_Ranon JF Michael_Cooper Kelly_Ford Cooper cyns Joshue +1.425.895.aabb Greg Léonie_Watson Found Date: 28 Jul 2011 Guessing minutes URL: http://www.w3.org/2011/07/28-html-a11y-minutes.html People with action items: rich WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]