W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2011

Special Teleconference Minutes for 1 August

From: Janina Sajka <janina@rednote.net>
Date: Mon, 1 Aug 2011 15:44:24 -0400
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20110801194424.GF3536@sonata.rednote.net>
Minutes from the special HTML-A11Y Task Force teleconference on Last Call Working
Draft bugs held on 1 August are provided below in text and are available
as hypertext at:



                                                           - DRAFT -

                                          HTML Accessibility Task Force Teleconference

01 Aug 2011

   See also: IRC log


          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

          Joshue_O_Connor, Marco_Ranon


          Greg, JF, janina


     * Topics
         1. Forms
         2. Focus section
         3. Landmarks
         4. Interactive Element
         5. Global issues
     * Summary of Action Items

   <trackbot> Date: 01 August 2011

   <Judy> scribe: Greg

   <MichaelC> Spec Review

   <MichaelC> Spec Review tracking table


   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: 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

   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:

   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
   ... 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

   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: 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 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

   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:

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


   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



   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"


   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

   <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]


   <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

   <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

   <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

Summary of Action Items

   [End of minutes]

Scribes: Greg, JF, janina
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


Janina Sajka,	Phone:	+1.443.300.2200

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)
Received on Monday, 1 August 2011 19:44:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:22 UTC