W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

01 Aug 2011

See also: IRC log

Attendees

Present
Greg, Michael_Cooper, Judy, Janina_Sajka, Cynthia_Shelly, +44.207.391.aaaa, Lynn_Holdsworth, kford, JF, Katie_Haritos-Shea, Steve_Faulkner, Rich_Schwerdtfeger, Laura_Carlson
Regrets
Joshue_O_Connor, Marco_Ranon
Chair
Janina_Sajka
Scribe
Greg, JF, janina

Contents


<trackbot> Date: 01 August 2011

<Judy> scribe: Greg

<MichaelC> Spec Review

<MichaelC> Spec Review tracking table

Forms

CS: Josh sent feedback that the examples don't talk about why things are done the way they're done, and importance of using the right control.
... Agreed, and feedback on specific examples.
... "Labels represents a caption" sounds strange, but that's editorial.
... Should ask Josh to file an Editorial bug; this is issue 2 on his review.

MC: Noting it in the Wiki.

CS: Mark's feedback is new input type has usability and accessibility input, and at times contradictory. CS agrees, but not specific enough to be actionable.
... Regular expression pattern for validation pattern is great feature, but using title attribute is inappropriate for providing user-friendly hint.
... His description is complete enough to file; but unclear if he's available this week.
... Greg Lowney's feedback on lack of tri-state and indeterminate checkboxes. Agreed that's a problem.
... Remembers discussion but not why it's not included in the spec.

JF: Could be because how HTML check boxes are inherently two state; making it three state would mean that testing it would require testing a value, which is not backwards compatible.

CS: Thinks it's legitimate.

JS: Agrees.

MC: Noting in Wiki that Greg should file bug that acknowledges the backwards compatibility issue.
... The user cases will be useful for the audience, moreso than harmonizing with ARIA.

CS: Nice to have some form features outside of forms. Also spec needs better a glossary.

Discussion of timeline.

<MichaelC> QA spec guidelines on terms

MC: W3 guidelines suggests terms should be defined, which implies a glossary.

CS: Who would be best source for request for glossary?

JB: Difficulty would be if glossaries need to be normative. They also tend to generate lots of comments because they typically have less work and time put in on them.

JS: In ISO glossary definitions are supposed to function as drop-and-replace for term.

JB: That is not yet requirement for W3C but it is a trend in W3C.

JS: Happy to have this be a PF request because a well-done and easy-to-understand spec helps adoption.

CS: 4.10.1.1 all form elements in this example are wrapped in P tags.
... This seems wrong, but it even has a sentence recommending it.
... Should not be disallowed, but probably should not be recommended for use in every form.

MC: Formatting issue, so it's not bad to do it.
... Content model of form content is flow content which can be nearly anything.

CS: Seems unnecessarily and inappropriate, so she'll file private bug.

GL: Doesn't seem appropriate to me, either. If one is navigating by paragraphs, wouldn't necessarily want each control to be treated as own paragraph.

CS: They're using <label> everywhere, never using <example for> which we're recommending.

MC: Agreed the examples should use <example for>.

JS: Examples don't exemplify best practices.

CS: Should we file a general bug, or several specific bugs?

MC: Suggests an all-in-one bug would be useful if we submit some drop in text to use, but without it the editor is likely to bounce it back requesting one issue per bug.
... We could file independent bugs listed as depending on a general bug.
... Noting in Wiki that CS will file general bug and specific, dependent bugs.
... Same for button for submit.
... Notes that <button> has more styling capabilities than <submit>.

CS: Seems strange to use a generic button when there's a specific button, but perhaps there are cases where it provides more features.
... Could provide bug suggesting a bug that button support type=submit.

JS: Notes that there are keyboard issues with button in some UAs.

MC: Noting this in the wiki.

CS: 4.10.4 Fieldset.
... Why is fieldset barred from validation, yet supports validation methods?
... Various things don't participate in automatic validation based on patterns, fieldset being one of them. Yet fieldset still supports the associated methods. Not accessibility, but strange.

MC: Note in wiki that CS will submit as a private bug.

CS: 4.10.5 all examples are about hiding and showing text, need to provide more examples of non-interactive use for grouping and labeling. This could probably be copied from HTML4 spec.

Discussion of whether this should be submitted with a11ytf keyword.

KF: Fieldset and legend make forms significantly more usable, especially in accessibility cases.

MC: Noting in wiki to submit it as a11ytf bug.

CS: Form controls inside legend e.g. <legend><label><input>text<label><legend>

MC: Does appear to be legal in HTML4, but never seen it used in practice.
... noting in spec need to discuss accessibility implications of form controls in legend.

CS: 4.10.6 Label. Read this paragraph many times, seems contradictory: “The label element's exact default presentation and behavior, in particular what its behavior might be, if anything, should match the platform's label behavior. The activation behavior of a label element for events targetted at interactive content descendants of a label element, and any descendants of those interactive...
... content descendants, must be to do nothing.”
... It says the default behavior should be to do nothing, and to do platform behavior.

MC: The second sentence is no longer in the TR draft.

GL: Appears only on http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html at this point.

JS: They'll always accept bugs against latest TR.

MC: Appears to be added since last call.

GL: Reviewing TR means some more recent bugs will be missed.

MC: Being able to click on implicit label provides larger mouse target, thus valuable.
... Notes in Wiki that CS will submit bug noting problem was introduced after last call draft.

JB: We need to be careful that we note what we're commenting against any time it's not the TR document.
... Presumably anything not in TR would presumably have different timeline for bug filing.

CS: Was told we should file bugs against most recent spec, and every bug reported by 3 August will be treated the same.
... Not convinced we'll get extra time to review things changed after last call.

MC: They're not using Version field in Bugzilla to track which version a bug is against, so have to note in description.

GL: Would be helpful to produce diff between TR and editor's draft, check it quickly for red flags.

<Stevef> http://html5.org/tools/web-apps-tracker

SF: Suggest more practical to go through tracker. It's not just HTML5. Could go back to any date and see whether changes were editorial, etc.

<JF> Steve's CP for meta generator: http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming

Side discussion of Steve Falkner's issues while he's on the call.

SF will look at scripting section.

CS: New feature in HTML5 where control have multiple labels, whereas in HTML4 there was one label per control.

GL: It would be useful for API to query the most specific label for a control, then the one above that (e.g. group box), and above that (e.g. tab), etc. However, that may not be what this is about.

MC: Notes that in HTML4 one could create multiple labels for control using the for attribute.

CS: Yet found a sentence in HTML4 saying the opposite.

MC: Noting in wiki it's will be discuss for task force.
... May need to tweak ARIA name calculation to reflect this.

CS: Example that uses implicit label and small element, etc.:

<p> <label>Full name: <input name=fn> <small>Format: First Last</small></label></p>

<p> <label>Age: <input name=age type=number min=0></label></p>

<p> <label>Post code: <input name=pc> <small>Format: AB12 3CD</small></label></p>

4.10.7 Input http://dev.w3.org/html5/spec/the-input-element.html#the-input-element'

CS: Again TF needs to discuss this, might affect name calculation.

MC: This is providing help text but using small tag is not necessarily best way to do it.

CS: In general, having attributes that are only valid with certain types is confusing.
... In HTML 4, it’s a common error to use alt on input other than type=img. The design seems likely to cause more of that sort of confusion. Can any of the attributes be made applicable to all input types, with specified mapping behavior?
... People use alt where not supported, think they've done accessibility when they have not.
... This mistake is now possible in many more cases than in HTML4.
... Most authors will never consult the table telling which attributes are legal with which types.

MC: Input elements being overloaded has been with us for a long time.

CS: Much worse because many more instances.

MC: Would have been nice to add native elements and deprecate the input element.

CS: No amount of documentation will prevent many, many predictable author errors.
... May be too late to get it fixed, but should start the discussion with them.

MC: Note in wiki that CS will file bug acknowledging there is history to work with but would like to identify path forward, mark as task force bug.

JF: Situation with validators earlier, that flagged things as not the recommended approach.

CS: Better to fix in HTML5 because it's a new feature which will introduce new problems.
... Going through remaining comments quickly.

<JF> http://wufoo.com/html5/attributes/02-autofocus.html

CS: Notes focus method messes up screen readers; would autofocus as well?
... Seems size, height, and width attributes should be deprecated, recommend CSS.

MC: That will be task force bug.

JF: Aren't there issues using CSS to style form controls?

CS: input.form...
... Allow associating a control with a form other than the form it is inside of.

Agreement that's a problem.

CS: List...agreement.
... Placeholder. What should users put in here, vs. label, vs. title. In accessibility API, I think this maps to accname, not value as current fake-placeholders do. How does it play with other things in name calculation? What should be read if there is a label and a placeholder

MC: Agreed useful feature but we have to work out how it should be used.

CS: What is a value sanitation algorithm? Please define what this is supposed to do. Links within the section go to the top of the section.
... Is the second sentence referring to immutable objects? It seems to apply to mutable, but doesn’t make sense
... When content was pasted into the wiki, in some cases words that were links were replaced by numbers that are links.
... Readonly attribute can make input elements immutable.
... Suggestion is to provide a table in the spec listing all cases where readonly attribute makes things immutable.

MC: Noting on wiki that CS will file one bug on contradiction in the one paragraph, and another recommending table of when readonly makes things immutable, both task force bugs.

CS: Input type can be changed dynamically. This is inconsistent with ARIA role, which cannot. Is that ok? It seems unlikely that either will change at this point. Will need to be considered for API mapping.

JF: This will break AT.

<JF> s/RS?RS

CS: Apparently it was a big debate a year ago, already implemented.

RS: We should not back off on a change we know will break AT.

JS: Will file bug, decide later how hard we'll fight for it, discuss later.

CS: Not accessibility, but it would be nice if <input type=email multiple> could split on semi-colon as well as comma
... will file as private bug.
... Is there value to allowing some form of friendly name in email fields? When you paste from email programs, this is often included, and it’s nice to be able to keep the friendly names around. Cognitive, maybe?
... This was explicitly removed from earlier versions.
... Friendly names are important for many people.

MC: Friendly names important, but people who aren't copying and pasting won't know the syntax to use, where to use brackets, etc. Could suggest two form controls, one for address and one for friendly name.

GL: losing friendly names is an accessibility issue because of cognitive load.

CS: Security issues with autocomplete or pattern on password? Not accessibility bug.
... Still concerning that date and time elements don’t have controls specified for them. This seems likely to lead to inconsistent UI, which may be confusing to AT users.
... True with other controls as well.

MC: Agreed, worried about other controls that might appear.
... Discussed earlier and decided it's a UAAG issue.

CS: People told her two years ago it was too late to change it.
... Thinks Opera is the only browser with native date and color pickers.
... Some OSs have native color pickers, not sure about calendar controls.

Discussion of whether native controls are keyboard accessible.

Also how controls need to support platform accessibility API.

CS: Form controls not being CSS stylable is major reason authors use custom controls.

MC: Will enter bug on wiki.

CS: Range says that the exact number is not important, but it renders as a slider. There are sliders where the exact number is important. “The user agent could pick which one to display based on the dimensions given in the style sheet. This would allow it to maintain the same resolution for the tick marks, despite the differences in width.” This is very vague. These different presentations..


.

scribe: should be controlled with CSS, not the browser.

MC: It says this to distinguish it from a number control.

<Laura> Thanks

MC: Noting in wiki conflating number and range.

CS: Number’s control is a “text box or spinner control.” Need to pick one so we know what accessibility role to map it to

GL: There's advantage for letting user agent to override default presentation, e.g. if user finds number easier than graphical presentation, should be able to request that.

CS: That raises many problems.

GL: Please include me in that discussion, even if I'm not normally on PF calls.

CS: More on radio and checkboxes, need to require labels, not required now.
... Input type accept should be extensible.
... Will submit that as private bug.
... Input type image says behavior changes if the image is not available.
... HTML4 has something similar that no one seems to implement.

MC: Will note in wiki bug will be filed.
... Also noting more research needed.

CS: “The alt attribute provides the textual label for the alternative button for users and user agents who cannot use the image. The alt attribute must also be present, and must contain a non-empty string.” Needs a rewrite. The alt attribute provides a text equivalent for the image button. Not sure what an “alternative button” is…

MC: Noting in wiki that CS will submit task force bug.

CS: “A user agent may allow the user to override the autocompletion state and set it to always on, always allowing values to be remembered and prefilled), or always off, never remembering values. However, the ability to override the autocompletion state to on should not be trivially accessible, as there are significant security implications for the user if all values are always remembered,...
... regardless of the site's preferences.” Implications for cognitive. Some users will need to set this all the time. Also, I’m not sure what “trivially accessible” means. I think it is advice on UI design for the browser. Should that be in a normative section? Is the an RFC SHOULD? Use a different word than accessible.

MC: Will note in wiki that CS will file a task force bug.

<JF> scribe: JF

<Greg> GL: I actually disagree with the suggestion that the spec shouldn't include advice on UI design for browsers. Including it can reduce the number of problematic implementations by developers, and also also helps authors understand the implications of their choices. Advice of this nature is included in many places in the spec, e.g. "Browsers should take extreme care when interacting with...

<Greg> ...external content intended for plugins."

CS: Is list just for making combo-boxes? May be a mapping issue?

need to figure out the implementation

GL: while might be for defining a combo box, different UA might need to render that differently

CS: we don't agree here
... Is Title enough for hinting? bigger issue is that it doesn't always render (keyboard and touch interfaces)

MC: we really need a help-text type attribute

GL: one other issue i am concerned about is an attribute do do thta - not sure if we should create a new attribute or re-use an existing one

MC: @title has too many uses

and the fact that microformats have used @title is another reason why we should avoid using it for a11y

CS: a global attribute might be useful

GL: I think I had suggested it before

MC: we've not discussed it today'

will note that Greg to file a bug

CS: 4.10.7.4 Common event behaviors

<Laura> Have to go now. Bye.

Why does color support autocomplete? What does autocomplete on color do?

CS: suggests a color contrast function for color-pickers

GL autocomplete would make sense when using named color values

CS: spec needs to be clearer
... Anyone see issues with wrap=hard?

GL: it makes reading a block of text if hard returns are inserted in a context that some users would be readin git

but it's unclear where this would be used.

it should be rendered on output, not input

CS: tend to agree, but don't really see this as an a11y issue

GL: would like to see a note that suggests this might introduce a11y issues

dependent on devices, etc.

MC: multi-edits on a wiki for example

KF: understand that this might not affect screen readers, but see how this could get very confusing

CS: 4.10.18 association of controls and forms

seems like some WCAG work needed here

Cyns to add to WCAG wiki

4.10.22.2 Implicit submissions

GL: so should this follow platform conventions?

CS: not sure - seems this might foul up data

GL: I think staying with platform conventions is the better way

MC: inclined to think that we don't want platform differences

GL: this means that web apps behave differently than native apps
... think the spec should leave this to UAAG to help provide guidance

(GL gets roped into filing the bug)

Announcer: this now concludes our review of forms...

JS: should we look at keyboard next?

MC: looking at focus makes sense - we need to look at the big stuff

Focus section

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

GL: I reviewed pretty much all of this, and then submitted some suggestions at the end

took a high-level view of how a spec should be compared against keyboard access

JS: a while back PF (with Greg Rosmaitia driving this) came to pretty much similar content

GL: would love to have some time to map the two against each other

note that there is no glossary that distinguishes between global and local instances

eg: accesskey issues

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

2 use cases and a recommendation

Sequential navigation to all elements that take focus or input

disagrees with current spec text

JS: sounds like a bug - agree with assertion

CS: there is a case where some screen readers where display:none places content into the dom, affecting the state to something never intended

worried about getting applications into states they cannot recover from

GL: will include a note specifically minding that this does not include things with display: none

JF: there is also @hidden and aria-hidden

GL so there are 3 ways of hiding content to make it non-operable

CS: yes

MC: visibility:hidden?

wouldn't want that to be focusable

JS: sounds like a discuss

GL: will file a bug
... Navigation to and through non-editable content

i.e. caret browsing

Q: does HTML5 have any issues with caret browsing?

CS: don't think this is an issue

JS: same as HTML4

GL: if HTML5 is defining tab order, this should be noted in the spec

MC: sounds like we should define what caret browsing does

CS: not sure if the behavior of caret browsing is part of the mark-up

GL: if there was something that used MUST then that would introduce a problem

MC: would like to see more support for caret browsing - seems like a bug should be filed

not sure what part of the spec this is related to

might also have impact on contenteditable

JS: not clear on the relationship between this and tab browsing

GL: tab-order doesn't track the caret

GL tab-order and caret postion need to be synched

GL: will file this as a bug

JS: if we are going to be giving this kind of help - if we return to a prior-page, shouldn't you resume where you left off?

GL: Preventing validation from trapping focus
... not sure if HTML5 is defining this or if it implies that UAs cannot navigate away from a form input

CS: nothing really in the spec that talks about input validation
... seems those are scripted issues
... might want to look to see if there is a place to insert a note specifically mentioning this issue

GL: Reading and navigation order
... proposes orientation="columns"

[discussion of values for the suggested attribute]

MC: we need to discuss more fully

CS: keep it really short else it becomes a rat-hole

GL: Facilitate navigating related pages

<cyns> http://www.w3.org/TR/2011/WD-html5-20110525/links.html#sequential-link-types

CS: there is a link feature for this already

MC: this is already defined for the <a> element

GL: Shortcut Keys (aka accesskeys and hot keys)

JS: this is a large discussion issue
... one point that is worth noting is Greg's mention of negociation

MC: we generally get tangled on keyboard access versus accesskey issues

we should stay away from accesskey and focus on keyboard access issues

there are multiple requirements pages, and Greg has added more in this wiki

MC: not sure what bug to file - we know that there are changes needed, but not sure what changes they are
... there is/was the XHTML2 access element idea

<Zakim> MichaelC, you wanted to talk about key access requirements vs accesskey specifically and to talk about other sources of requirements

CS: this is a non-trivial task

<MichaelC> XTech requirements: http://www.w3.org/wiki/PF/XTech/HTML5/AccesskeyRequirements

<MichaelC> TF requirements: http://www.w3.org/WAI/PF/HTML/wiki/Access

<MichaelC> UAWG / Greg requirements: http://www.w3.org/WAI/UA/work/wiki/HTML5_review_by_UAWG_notes#Keyboard_Use_Cases_and_Recommendations

JS: this is more than just an a11y issue - D. Singer noted that this will impact on new, emerging platofrms/devices

+q

MC: what should we be doing then?

GL: we should file multiple bugs

[discussion on how to proceed]

JF: one big bug would suffice

MC: do we have an issue with attaching a11yTF to the bugs?

JS: I think we don't

GL: this has been broken forever, and HTML5 is the opportunity to fix it

http://www.w3.org/WAI/UA/work/wiki/HTML5_review_by_UAWG_notes#Keyboard_Use_Cases_and_Recommendations

me/

MC: will note that there is much to do here, and will leave it open
... will likely end up creating a sub-group on this

GL: should we just move past all the other issues and I will just file the bugs?

MC: we should move on to the "emulating non keyboard operations" heading

JS: sounds like intentional events issue
... Gez Lemon had some comments on this a while ago. According to M(tm)S this has been addressed by the editor

JF: file these as bugs

GL: will file
... should the spec define handling shorcut conflicts

or should the author be able to suggest ways to do this

JS: seems again that this is not going to be solved here - go ahead and file more bugs

<img src="western-australia.png"

property="keywords"

content="flags swan union-jack"

alt="Flag of Western Australia" />

GL: so should we raise a bug in bugzilla

JS: I think we discussed last week thta this was a "feature complete" issue

CS: the other issue is that there is a lot of work to do here, we might not be able to get it done on time

it's a legitimate question

if it can be done in the time-frame then great, else...

JB: what is needed for HTML5 to support a11y - if it turns out that bugs have larger benfit, great, if it turns out that it is an intractable issue then we will need to accept that and move on

CS: not opposed to filing the bug, just not sure if it will make the deadline

GL: are we talking about the keywords issue, or the more focused accesskey issue?

CS: accesskey isn't a good idea as everyone knows it is broken

GL: OK, so I will file a larger bug, with accesskey being but one example

JS: we should discuss what to do about other things we've not addressed yet

MC: there remains interactive elements, and some comments about landmarks as well

<janina> scribe: janina

cs: I'm assigned other sections to find reviewers, I expect to get some done, probably not all

<JF> JS: we could ask for an extension

<JF> CS: what about people just filing bugs and not tagging them with the TF tag

<JF> JB: we will likely need a quick hour or so before end of biz on the 3rd

discussion on how to deal with reviews we know arecoming

<JF> suspect that we could do what Cyns suggested - file bugs as individual bugs and then review later to add the TF tag

<JF> JS; what we are saying then is for any further reviews ask that bugs also be filed

<JF> and then MC and JS will watch them and make sure nothing slips

<JF> MC: in the past week there were 35 a11y bugs, and of those 21 are tagged a11yTF

<JF> MC seems there are quite a few still to come: cyns ~20, Greg a bunch more, and the wiki seems to have others that have not been filed as well

<JF> [discussion of next steps and when/if we meet again before midnight wednesday]

Landmarks

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

<JF> JS; we will meet again on Wednesday Aug. 3 @ 5:30 PM boston time for 1 hour

<JF> 4.13.2 Bread crumb navigation - Leonie should file a bug

<JF> [explaining what a tag cloud is for some attendees]

<JF> CS: there is no tag-cloud element. the spec explains why a tag-cloud element was not created

<JF> CS: perhaps these should be removed from the spec, and simply provide a list of things not addressed

<JF> CS: we should file a bug to remove this from the spec

<JF> we either need to fix the examples or remove the section

Interactive Element

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

<JF> GL: Facilitate grouping of menu items

<JF> Recommendation: The HTML5 specification should note that user agents may override the default presentation described in order to comply with user preferences.

<JF> Recommendation: In order to facilitate structural or hierarchical navigation and progressive disclosure, the HTML5 specification should emphasize giving names to groupings, including to groups of menu items.

<MichaelC> -> http://www.w3.org/TR/2011/WD-css3-images-20110712/ CSS Image Values and Replaced Content Module http://www.w3.org/TR/2011/WD-css3-images-20110712/

<scribe> scribe: janina

Global issues

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

<Greg> Issue: Should the HTML5 spec define a standard, platform-independent way for content to query the user agent's accessibility settings, and by extension platform settings that are known to the user agent? Are there any equivalents today?

<trackbot> Created ISSUE-2 - Should the HTML5 spec define a standard, platform-independent way for content to query the user agent's accessibility settings, and by extension platform settings that are known to the user agent? Are there any equivalents today? ; please complete additional details at http://www.w3.org/WAI/PF/HTML/track/issues/2/edit .

Greg to file bug on providing a method for user agent to declare AT in use

Greg also to file a bug noting there are privacy concerns with the former, and also

that there are privacy concerns around inferring dsability from tracking events

We will pass these concerns also to the new W3C privacy WG

<MichaelC> trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/08/01 19:42:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/E.g./Also spec needs better /
Succeeded: s/JS/CS/
Succeeded: s/JS/JF/
WARNING: Bad s/// command: s/JF?RS
Succeeded: s/JF/RS/
Succeeded: s/jfoliot@stanford.edu//
Found Scribe: Greg
Inferring ScribeNick: Greg
Found Scribe: JF
Inferring ScribeNick: JF
Found Scribe: janina
Inferring ScribeNick: janina
Found Scribe: janina
Inferring ScribeNick: janina
Scribes: Greg, JF, janina
ScribeNicks: Greg, JF, janina
Default Present: Greg, Michael_Cooper, Judy, Janina_Sajka, Cynthia_Shelly, +44.207.391.aaaa, Lynn_Holdsworth, kford, JF, Katie_Haritos-Shea, Steve_Faulkner, Rich_Schwerdtfeger, Laura_Carlson
Present: Greg Michael_Cooper Judy Janina_Sajka Cynthia_Shelly +44.207.391.aaaa Lynn_Holdsworth kford JF Katie_Haritos-Shea Steve_Faulkner Rich_Schwerdtfeger Laura_Carlson
Regrets: Joshue_O_Connor Marco_Ranon
Found Date: 01 Aug 2011
Guessing minutes URL: http://www.w3.org/2011/08/01-html-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]