- 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>
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:
http://www.w3.org/2011/08/01-html-a11y-minutes.html
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
SV_MEETING_CHAIR
Scribe
Greg, JF, janina
Contents
* 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
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
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
sip:janina@asterisk.rednote.net
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