14:55:42 <RRSAgent> RRSAgent has joined #html-a11y
14:55:42 <RRSAgent> logging to http://www.w3.org/2011/08/01-html-a11y-irc
14:55:44 <trackbot> RRSAgent, make logs world
14:55:44 <Zakim> Zakim has joined #html-a11y
14:55:46 <trackbot> Zakim, this will be 2119
14:55:46 <Zakim> ok, trackbot; I see WAI_PF(A11Y)11:00AM scheduled to start in 5 minutes
14:55:47 <trackbot> Meeting: HTML Accessibility Task Force Teleconference
14:55:47 <trackbot> Date: 01 August 2011
15:01:04 <Zakim> WAI_PF(A11Y)11:00AM has now started
15:01:11 <Zakim> +Greg
15:01:25 <Zakim> +Michael_Cooper
15:01:59 <Greg> Greg has joined #html-a11y
15:02:12 <Zakim> +??P1
15:02:43 <Zakim> +Judy
15:02:43 <MichaelC> zakim, ??P1 is Janina_Sajka
15:02:44 <Zakim> +Janina_Sajka; got it
15:04:19 <Lynn_Holdsworth> Lynn_Holdsworth has joined #html-a11y
15:04:29 <Zakim> +[Microsoft]
15:04:56 <MichaelC> zakim, Microsoft is Cynthia_Shelly
15:04:56 <Zakim> +Cynthia_Shelly; got it
15:05:03 <Zakim> + +44.207.391.aaaa
15:05:44 <MichaelC> zakim, aaaa is Lynn_Holdsworth
15:05:44 <Zakim> +Lynn_Holdsworth; got it
15:05:55 <janina> zakim, aaaa is Lynn
15:05:55 <Zakim> sorry, janina, I do not recognize a party named 'aaaa'
15:06:36 <kford> kford has joined #html-a11y
15:07:43 <Judy> scribe: Greg
15:07:56 <Zakim> +[Microsoft]
15:08:08 <kford> zakim, microsoft is kford
15:08:08 <Zakim> +kford; got it
15:08:25 <MichaelC> agenda+ bugs we agreed to file
15:09:59 <MichaelC> -> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/All Spec Review
15:10:10 <MichaelC> -> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review Spec Review tracking table
15:10:39 <Greg> topic: Forms
15:12:05 <MichaelC> regrets: Joshue_O_Connor, Marco_Ranon
15:12:50 <Greg> 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.
15:12:55 <JF> JF has joined #html-a11y
15:13:00 <Greg> CS: Agreed, and feedback on specific examples.
15:13:25 <Zakim> +JF
15:13:26 <Greg> CS: "Labels represents a caption" sounds strange, but that's editorial.
15:13:57 <Greg> CS: Should ask Josh to file an Editorial bug; this is issue 2 on his review.
15:14:26 <Greg> MC: Noting it in the Wiki.
15:15:01 <Greg> 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.
15:16:09 <Greg> CS: Regular expression pattern for validation pattern is great feature, but using title attribute is inappropriate for providing user-friendly hint.
15:17:16 <Greg> CS: His description is complete enough to file; but unclear if he's available this week.
15:17:37 <Greg> CS: Greg Lowney's feedback on lack of tri-state and indeterminate checkboxes. Agreed that's a problem.
15:17:57 <Greg> CS: Remembers discussion but not why it's not included in the spec.
15:18:51 <Greg> 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.
15:19:18 <Greg> CS: Thinks it's legitimate.
15:19:22 <Greg> JS: Agrees.
15:20:11 <Greg> MC: Noting in Wiki that Greg should file bug that acknowledges the backwards compatibility issue.
15:20:59 <Greg> MC: The user cases will be useful for the audience, moreso than harmonizing with ARIA.
15:21:47 <Greg> CS: Nice to have some form features outside of forms. E.g. a glossary.
15:22:26 <Greg> s/E.g./Also spec needs better /
15:23:01 <Greg> Discussion of timeline.
15:24:40 <MichaelC> -> http://www.w3.org/TR/qaframe-spec/#define-terms-section QA spec guidelines on terms
15:25:07 <Zakim> +Katie_Haritos-Shea
15:25:07 <Greg> MC: W3 guidelines suggests terms should be defined, which implies a glossary.
15:25:44 <Greg> CS: Who would be best source for request for glossary?
15:27:02 <Greg> 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.
15:27:39 <Greg> JS: In ISO glossary definitions are supposed to function as drop-and-replace for term.
15:27:53 <Greg> JB: That is not yet requirement for W3C but it is a trend in W3C.
15:28:49 <Greg> JS: Happy to have this be a PF request because a well-done and easy-to-understand spec helps adoption.
15:29:22 <Greg> CS: 4.10.1.1 all form elements in this example are wrapped in P tags.
15:29:47 <Greg> CS: This seems wrong, but it even has a sentence recommending it.
15:30:05 <Greg> CS: Should not be disallowed, but probably should not be recommended for use in every form.
15:30:31 <Greg> MC: Formatting issue, so it's not bad to do it.
15:30:57 <Greg> MC: Content model of form content is flow content which can be nearly anything.
15:31:11 <Greg> CS: Seems unnecessarily and inappropriate, so she'll file private bug.
15:32:15 <Greg> 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.
15:33:01 <Greg> CS: They're using <label> everywhere, never using <example for> which we're recommending. 
15:33:21 <Greg> MC: Agreed the examples should use <example for>.
15:33:46 <Greg> JS: Examples don't exemplify best practices.
15:34:08 <Greg> JS: Should we file a general bug, or several specific bugs?
15:34:13 <Zakim> +??P0
15:34:18 <Greg> s/JS/CS/
15:35:00 <Greg> 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.
15:35:20 <Stevef> Stevef has joined #html-a11y
15:35:30 <Greg> MC: We could file independent bugs listed as depending on a general bug.
15:35:50 <Greg> MC: Noting in Wiki that CS will file general bug and specific, dependent bugs.
15:36:09 <Greg> MC: Same for button for submit.
15:36:38 <Greg> MC: Notes that <button> has more styling capabilities than <submit>.
15:37:11 <Greg> CS: Seems strange to use a generic button when there's a specific button, but perhaps there are cases where it provides more features.
15:38:15 <Greg> CS: Could provide bug suggesting a bug that button support type=submit. 
15:38:45 <Greg> JS: Notes that there are keyboard issues with button in some UAs.
15:38:53 <Greg> MC: Noting this in the wiki.
15:39:02 <Greg> CS: 4.10.4 Fieldset.
15:39:27 <Greg> CS: Why is fieldset barred from validation, yet supports validation methods?
15:40:15 <Greg> CS: 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.
15:40:29 <Greg> MC: Note in wiki that CS will submit as a private bug.
15:41:25 <Greg> 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.
15:42:16 <Greg> Discussion of whether this should be submitted with a11ytf keyword.
15:43:10 <Greg> KF: Fieldset and legend make forms significantly more usable, especially in accessibility cases.
15:43:27 <Greg> MC: Noting in wiki to submit it as a11ytf bug.
15:45:05 <Greg> CS: Form controls inside legend e.g. <legend><label><input>text<label><legend> 
15:45:23 <Greg> MC: Does appear to be legal in HTML4, but never seen it used in practice.
15:45:51 <Greg> MC: noting in spec need to discuss accessibility implications of form controls in legend.
15:46:30 <Greg> 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...
15:46:31 <Greg> ...content descendants, must be to do nothing.” 
15:47:31 <Greg> CS: It says the default behavior should be to do nothing, and to do platform behavior.
15:47:54 <Greg> MC: The second sentence is no longer in the TR draft.
15:48:45 <Greg> GL: Appears only on http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html at this point.
15:49:02 <Greg> JS: They'll always accept bugs against latest TR.
15:49:11 <Greg> MC: Appears to be added since last call.
15:49:55 <Greg> GL: Reviewing TR means some more recent bugs will be missed.
15:51:10 <Greg> MC: Being able to click on implicit label provides larger mouse target, thus valuable.
15:51:42 <Greg> MC: Notes in Wiki that CS will submit bug noting problem was introduced after last call draft.
15:52:44 <Greg> JB: We need to be careful that we note what we're commenting against any time it's not the TR document.
15:53:07 <Greg> JB: Presumably anything not in TR would presumably have different timeline for bug filing.
15:53:42 <Greg> CS: Was told we should file bugs against most recent spec, and every bug reported by 3 August will be treated the same.
15:53:59 <Greg> CS: Not convinced we'll get extra time to review things changed after last call.
15:54:26 <Greg> MC: They're not using Version field in Bugzilla to track which version a bug is against, so have to note in description.
15:55:08 <Greg> GL: Would be helpful to produce diff between TR and editor's draft, check it quickly for red flags.
15:55:27 <MichaelC> zakim, ??P0 is Steve_Faulkner
15:55:27 <Zakim> +Steve_Faulkner; got it
15:56:07 <Stevef> http://html5.org/tools/web-apps-tracker
15:56:22 <Greg> 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. 
15:57:01 <JF> Steve's CP for meta generator: http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming
15:57:03 <Greg> Side discussion of Steve Falkner's issues while he's on the call.
15:58:27 <Zakim> -Steve_Faulkner
15:58:29 <Greg> SF will look at scripting section.
15:59:30 <Greg> CS: New feature in HTML5 where control have multiple labels, whereas in HTML4 there was one label per control.
16:00:30 <Greg> 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.
16:01:17 <Greg> MC: Notes that in HTML4 one could create multiple labels for control using the for attribute. 
16:01:38 <Greg> CS: Yet found a sentence in HTML4 saying the opposite.
16:02:38 <Greg> MC: Noting in wiki it's will be discuss for task force.
16:03:00 <Greg> MC: May need to tweak ARIA name calculation to reflect this.
16:03:40 <Greg> CS: Example that uses implicit label and small element, etc.: 
16:03:42 <Greg> <p><label>Full name: <input name=fn> <small>Format: First Last</small></label></p> 
16:03:43 <Greg> <p><label>Age: <input name=age type=number min=0></label></p> 
16:03:45 <Greg> <p><label>Post code: <input name=pc> <small>Format: AB12 3CD</small></label></p> 
16:03:46 <Greg> 4.10.7 Input http://dev.w3.org/html5/spec/the-input-element.html#the-input-element'
16:04:14 <Greg> CS: Again TF needs to discuss this, might affect name calculation.
16:04:46 <Greg> MC: This is providing help text but using small tag is not necessarily best way to do it.
16:05:07 <Greg> CS:  In general, having attributes that are only valid with certain types is confusing.
16:05:31 <Greg> CS: 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? 
16:06:38 <Greg> CS: People use alt where not supported, think they've done accessibility when they have not.
16:07:03 <Greg> CS: This mistake is now possible in many more cases than in HTML4.
16:08:00 <Greg> CS: Most authors will never consult the table telling which attributes are legal with which types.
16:08:38 <Greg> MC: Input elements being overloaded has been with us for a long time.
16:08:48 <Greg> CS: Much worse because many more instances.
16:09:07 <Greg> MC: Would have been nice to add native elements and deprecate the input element.
16:09:31 <Greg> CS: No amount of documentation will prevent many, many predictable author errors.
16:10:08 <Greg> CS: May be too late to get it fixed, but should start the discussion with them.
16:10:37 <Greg> 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.
16:11:28 <Greg> JS: Situation with validators earlier, that flagged things as not the recommended approach.
16:11:40 <JF> s/JS/JF
16:11:44 <Greg> CS: Better to fix in HTML5 because it's a new feature which will introduce new problems.
16:12:51 <Greg> CS: Going through remaining comments quickly.
16:13:15 <JF> http://wufoo.com/html5/attributes/02-autofocus.html
16:13:47 <Greg> CS: Notes focus method messes up screen readers; would autofocus as well?
16:14:13 <Greg> CS: Seems size, height, and width attributes should be deprecated, recommend CSS.
16:14:28 <Greg> MC: That will be task force bug.
16:14:42 <Greg> JF: Aren't there issues using CSS to style form controls?
16:15:36 <Greg> CS: input.form...
16:16:23 <Greg> CS: Allow associating a control with a form other than the form it is inside of.
16:16:30 <Greg> Agreement that's a problem.
16:17:06 <Greg> CS: List...agreement.
16:17:30 <Greg> CS: 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 
16:18:00 <Greg> MC: Agreed useful feature but we have to work out how it should be used.
16:18:08 <richardschwerdtfe> richardschwerdtfe has joined #html-a11y
16:18:30 <Greg> 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. 
16:19:43 <Greg> CS: Is the second sentence referring to immutable objects? It seems to apply to mutable, but doesn’t make sense 
16:21:32 <Zakim> +Rich_Schwerdtfeger
16:23:14 <Greg> CS: When content was pasted into the wiki, in some cases words that were links were replaced by numbers that are links.
16:23:56 <Greg> CS: Readonly attribute can make input elements immutable.
16:24:32 <Greg> CS: Suggestion is to provide a table in the spec listing all cases where readonly attribute makes things immutable.
16:26:10 <Greg> 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.
16:26:51 <Greg> 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.  
16:27:10 <Greg> JF: This will break AT.
16:27:25 <JF> s/JF?RS
16:27:31 <JF> s/JF/RS
16:27:31 <Greg> CS: Apparently it was a big debate a year ago, already implemented.
16:29:45 <Greg> RS: We should not back off on a change we know will break AT.
16:30:17 <Greg> JS: Will file bug, decide later how hard we'll fight for it, discuss later.
16:30:56 <Greg> CS: Not accessibility, but it would be nice if <input type=email multiple> could split on semi-colon as well as comma 
16:31:09 <Greg> CS: will file as private bug.
16:31:38 <Greg> CS: 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? 
16:32:18 <Greg> CS: This was explicitly removed from earlier versions.
16:32:43 <Greg> CS: Friendly names are important for many people.
16:33:22 <Greg> 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.
16:34:21 <Greg> GL: losing friendly names is an accessibility issue because of cognitive load.
16:34:48 <Greg> CS: Security issues with autocomplete or pattern on password?  Not accessibility bug.
16:34:57 <Greg> CS: 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. 
16:35:12 <Greg> CS: True with other controls as well.
16:35:56 <Greg> MC: Agreed, worried about other controls that might appear.
16:36:20 <Greg> MC: Discussed earlier and decided it's a UAAG issue.
16:36:43 <Greg> CS: People told her two years ago it was too late to change it.
16:37:40 <Greg> CS: Thinks Opera is the only browser with native date and color pickers.
16:38:05 <Greg> CS: Some OSs have native color pickers, not sure about calendar controls.
16:39:07 <Greg> Discussion of whether native controls are keyboard accessible.
16:40:40 <Greg> Also how controls need to support platform accessibility API.
16:41:49 <Greg> CS: Form controls not being CSS stylable is major reason authors use custom controls.
16:41:59 <Greg> MC: Will enter bug on wiki.
16:42:12 <Greg> 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..
16:42:13 <Greg> .
16:42:15 <Greg> ...should be controlled with CSS, not the browser. 
16:43:43 <Greg> MC: It says this to distinguish it from a number control.
16:43:45 <Laura> Laura has joined #html-a11y
16:44:23 <Laura> Thanks
16:44:45 <Greg> MC: Noting in wiki conflating number and range.
16:45:00 <Greg> 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
16:45:12 <Zakim> +Laura_Carlson
16:46:23 <Greg> 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.
16:46:30 <Greg> CS: That raises many problems.
16:47:04 <Greg> GL: Please include me in that discussion, even if I'm not normally on PF calls.
16:47:45 <Greg> CS: More on radio and checkboxes, need to require labels, not required now.
16:48:25 <Greg> CS: Input type accept should be extensible.
16:49:29 <Greg> CS: Will submit that as private bug.
16:50:27 <Greg> CS: Input type image says behavior changes if the image is not available.
16:51:04 <Greg> CS: HTML4 has something similar that no one seems to implement.
16:51:45 <jongund> jongund has joined #html-a11y
16:54:04 <Greg> MC: Will note in wiki bug will be filed.
16:54:23 <Zakim> -Lynn_Holdsworth
16:54:25 <Greg> MC: Also noting more research needed.
16:54:44 <Greg> 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… 
16:56:35 <Greg> MC: Noting in wiki that CS will submit task force bug.
16:56:59 <Greg> 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,...
16:57:00 <Greg> ...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. 
16:58:00 <Greg> MC: Will note in wiki that CS will file a task force bug.
17:01:26 <JF> scribe: JF
17:01:54 <Zakim> -Judy
17:02:16 <MichaelC> zakim, ping me in 10 minutes
17:02:16 <Zakim> ok, MichaelC
17:05:07 <Zakim> -Rich_Schwerdtfeger
17:09:10 <JF> zakim, who's here?
17:09:10 <Zakim> On the phone I see Greg, Michael_Cooper, Janina_Sajka, Cynthia_Shelly, kford, JF, Katie_Haritos-Shea, Laura_Carlson
17:09:12 <Zakim> On IRC I see jongund, Laura, richardschwerdtfe, JF, kford, Greg, Zakim, RRSAgent, Judy, cyns, janina, MikeSmith, MichaelC, trackbot, [tm]
17:11:35 <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...
17:11:37 <Greg> ...external content intended for plugins." 
17:12:00 <Zakim> +Judy
17:12:17 <Zakim> MichaelC, you asked to be pinged at this time
17:13:03 <JF> CS: Is list just for making combo-boxes?  May be a mapping issue?
17:13:12 <JF> need to figure out the implementation
17:13:44 <JF> GL: while might be for defining a combo box, different UA might need to render that differently
17:13:54 <JF> CS: we don't agree here
17:15:03 <JF> CS: Is Title enough for hinting? bigger issue is that it doesn't always render (keyboard and touch interfaces)
17:15:14 <JF> MC: we really need a help-text type attribute
17:15:43 <JF> 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
17:16:03 <JF> MC: @title has too many uses
17:16:27 <JF> and the fact that microformats have used @title is another reason why we should avoid using it for a11y
17:16:56 <JF> CS: a global attribute might be useful
17:17:09 <JF> GL: I think I had suggested it before
17:17:18 <JF> MC: we've not discussed it today'
17:17:25 <JF> will note that Greg to file a bug
17:18:05 <JF> CS: 4.10.7.4 Common event behaviors 
17:18:20 <Laura> Have to go now. Bye.
17:18:25 <Zakim> -Laura_Carlson
17:18:29 <JF> Why does color support autocomplete?  What does autocomplete on color do?  
17:19:10 <JF> CS: suggests a color contrast function for color-pickers
17:19:33 <JF> GL autocomplete would make sense when using named color values
17:19:41 <JF> CS: spec needs to be clearer
17:21:28 <JF> CS: Anyone see issues with wrap=hard? 
17:21:55 <JF> GL: it makes reading a block of text if hard returns are inserted in a context that some users would be readin git
17:22:08 <JF> but it's unclear where this would be used.
17:22:19 <JF> it should be rendered on output, not input
17:22:30 <JF> CS: tend to agree, but don't really see this as an a11y issue
17:22:52 <JF> GL: would like to see a note that suggests this might introduce a11y issues
17:23:06 <JF> dependent on devices, etc.
17:23:17 <JF> MC: multi-edits on a wiki for example
17:23:20 <kford> q+
17:23:46 <janina> ack k
17:24:10 <JF> KF: understand that this might not affect screen readers, but see how this could get very confusing
17:24:16 <kford> q-
17:24:50 <JF> CS: 4.10.18 association of controls and forms 
17:24:59 <JF> seems like some WCAG work needed here
17:25:21 <JF> Cyns to add to WCAG wiki
17:26:09 <JF> 4.10.22.2 Implicit submissions 
17:27:07 <JF> GL: so should this follow platform conventions?
17:27:15 <JF> CS: not sure - seems this might foul up data
17:27:29 <JF> GL: I think staying with platform conventions is the better way
17:27:53 <JF> MC: inclined to think that we don't want platform differences
17:28:22 <JF> GL: this means that web apps behave differently than native apps
17:28:53 <JF> GL: think the spec should leave this to UAAG to help provide guidance
17:29:06 <JF> (GL gets roped into filing the bug)
17:29:53 <JF> Announcer: this now concludes our review of forms...
17:30:16 <JF> JS: should we look at keyboard next?
17:30:42 <JF> MC: looking at focus makes sense - we need to look at the big stuff
17:31:00 <MichaelC> topic: Focus section
17:31:01 <MichaelC> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/All#Focus
17:31:45 <JF> GL: I reviewed pretty much all of this, and then submitted some suggestions at the end
17:32:13 <JF> took a high-level view of how a spec should be compared against keyboard access
17:32:28 <Zakim> -kford
17:34:07 <JF> JS: a while back PF (with Greg Rosmaitia driving this) came to pretty much similar content
17:34:21 <JF> GL: would love to have some time to map the two against each other
17:35:17 <JF> note that there is no glossary that distinguishes between global and local instances
17:35:28 <JF> eg: accesskey issues
17:36:39 <Greg> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/All#Navigation
17:37:02 <JF> 2 use cases and a recommendation
17:37:12 <JF> Sequential navigation to all elements that take focus or input 
17:37:28 <JF> disagrees with current spec text
17:37:50 <JF> JS: sounds like a bug - agree with assertion
17:38:51 <JF> CS: there is a case where some screen readers where display:none places content into the dom, affecting the state to something never intended
17:39:10 <JF> worried about getting applications into states they cannot recover from
17:39:32 <JF> GL: will include a note specifically minding that this does not include things with display: none
17:40:04 <JF> JF: there is also @hidden and aria-hidden
17:40:22 <JF> GL so there are 3 ways of hiding content to make it non-operable
17:40:27 <JF> CS: yes
17:41:02 <JF> MC: visibility:hidden?
17:41:13 <JF> wouldn't want that to be focusable
17:41:29 <JF> JS: sounds like a discuss
17:41:35 <JF> GL: will file a bug
17:41:45 <JF> GL: Navigation to and through non-editable content 
17:41:52 <JF> i.e. caret browsing
17:42:30 <JF> Q: does HTML5 have any issues with caret browsing?
17:42:37 <JF> CS: don't think this is an issue
17:42:44 <JF> JS: same as HTML4
17:42:59 <JF> GL: if HTML5 is defining tab order, this should be noted in the spec
17:43:09 <JF> MC: sounds like we should define what caret browsing does
17:43:28 <JF> CS: not sure if the behavior of caret browsing is part of the mark-up
17:43:49 <JF> GL: if there was something that used MUST then that would introduce a problem
17:44:14 <JF> MC: would like to see more support for caret browsing - seems like a bug should be filed
17:44:27 <JF> not sure what part of the spec this is related to
17:44:39 <JF> might also have impact on contenteditable
17:44:57 <JF> JS: not clear on the relationship between this and tab browsing
17:45:20 <JF> GL: tab-order doesn't track the caret
17:45:39 <JF> GL tab-order and caret postion need to be synched
17:45:56 <JF> GL: will file this as a bug
17:46:36 <JF> 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?
17:48:12 <JF> GL: Preventing validation from trapping focus 
17:50:13 <JF> GL: not sure if HTML5 is defining this or if it implies that UAs cannot navigate away from a form input
17:50:28 <JF> CS: nothing really in the spec that talks about input validation
17:50:37 <JF> CS: seems those are scripted issues 
17:51:00 <JF> CS: might want to look to see if there is a place to insert a note specifically mentioning this issue
17:51:18 <JF> GL: Reading and navigation order 
17:52:13 <JF> GL: proposes orientation="columns"
17:55:41 <JF> [discussion of values for the suggested attribute]
17:56:05 <JF> MC: we need to discuss more fully
17:56:26 <JF> CS: keep it really short else it becomes a rat-hole
17:57:04 <JF> GL: Facilitate navigating related pages 
17:58:01 <cyns> http://www.w3.org/TR/2011/WD-html5-20110525/links.html#sequential-link-types
17:58:15 <JF> CS: there is a link feature for this already
17:58:26 <JF> MC: this is already defined for the <a> element
17:59:15 <JF> GL: Shortcut Keys  (aka accesskeys and hot keys)
18:01:56 <MichaelC> q+
18:02:12 <MichaelC> q+ to talk about key access requirements vs accesskey specifically
18:02:25 <MichaelC> q+ to talk about other sources of requirements
18:03:27 <JF> JS: this is a large discussion issue
18:03:44 <JF> JS: one point that is worth noting is Greg's mention of negociation
18:04:29 <JF> MC: we generally get tangled on keyboard access versus accesskey issues
18:04:47 <JF> we should stay away from accesskey and focus on keyboard access issues
18:05:05 <JF> there are multiple requirements pages, and Greg has added more in this wiki
18:05:27 <JF> MC: not sure what bug to file - we know that there are changes needed, but not sure what changes they are
18:05:40 <Judy> zakim, who's here?
18:05:40 <Zakim> On the phone I see Greg, Michael_Cooper, Janina_Sajka, Cynthia_Shelly, JF, Katie_Haritos-Shea, Judy
18:05:42 <Zakim> On IRC I see jongund, richardschwerdtfe, JF, kford, Greg, Zakim, RRSAgent, Judy, cyns, janina, MikeSmith, MichaelC, trackbot, [tm]
18:05:59 <JF> MC: there is/was the XHTML2 access element idea
18:06:11 <MichaelC> ack me
18:06:11 <Zakim> MichaelC, you wanted to talk about key access requirements vs accesskey specifically and to talk about other sources of requirements
18:06:12 <JF> CS: this is a non-trivial task
18:07:10 <MichaelC> XTech requirements: http://www.w3.org/wiki/PF/XTech/HTML5/AccesskeyRequirements
18:07:19 <MichaelC> TF requirements: http://www.w3.org/WAI/PF/HTML/wiki/Access
18:08:29 <MichaelC> UAWG / Greg requirements: http://www.w3.org/WAI/UA/work/wiki/HTML5_review_by_UAWG_notes#Keyboard_Use_Cases_and_Recommendations
18:08:51 <JF> JS: this is more than just an a11y issue - D. Singer noted that this will impact on new, emerging platofrms/devices
18:09:45 <JF> +q
18:10:08 <JF> MC: what should we be doing then?
18:10:19 <JF> GL: we should file multiple bugs
18:10:21 <JF> ack JF
18:11:07 <MichaelC> ack j
18:12:13 <JF> [discussion on how to proceed]
18:13:05 <JF> JF: one big bug would suffice
18:13:22 <JF> MC: do we have an issue with attaching a11yTF to the bugs?
18:13:36 <JF> JS: I think we don't 
18:14:04 <JF> GL: this has been broken forever, and HTML5 is the opportunity to fix it
18:15:20 <JF> http://www.w3.org/WAI/UA/work/wiki/HTML5_review_by_UAWG_notes#Keyboard_Use_Cases_and_Recommendations
18:15:52 <JF> me/ jfoliot@stanford.edu
18:16:20 <JF> MC: will note that there is much to do here, and will leave it open
18:16:20 <MichaelC> s/jfoliot@stanford.edu//
18:17:22 <JF> MC: will likely end up creating a sub-group on this
18:18:30 <JF> GL: should we just move past all the other issues and I will just file the bugs?
18:18:45 <JF> MC: we should move on to the "emulating non keyboard operations" heading
18:19:22 <JF> JS: sounds like intentional events issue
18:20:21 <JF> JS: Gez Lemon had some comments on this a while ago. According to M(tm)S this has been addressed by the editor
18:21:43 <JF> JF: file these as bugs
18:22:06 <JF> GL: will file 
18:22:52 <JF> GL: should the spec define handling shorcut conflicts
18:23:10 <JF> or should the author be able to suggest ways to do this
18:26:21 <JF> JS: seems again that this is not going to be solved here - go ahead and file more bugs
18:30:55 <JF> <img src="western-australia.png"
18:30:56 <JF>       property="keywords"
18:30:58 <JF>       content="flags swan union-jack"
18:30:59 <JF>       alt="Flag of Western Australia" />
18:33:13 <JF> GL: so should we raise a bug in bugzilla
18:33:34 <JF> JS: I think we discussed last week thta this was a "feature complete" issue
18:34:08 <JF> 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
18:34:14 <JF> it's a legitimate question
18:34:27 <JF> if it can be done in the time-frame then great, else...
18:35:13 <JF> 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
18:35:34 <JF> CS: not opposed to filing the bug, just not sure if it will make the deadline
18:36:01 <JF> GL: are we talking about the keywords issue, or the more focused accesskey issue?
18:36:17 <JF> CS: accesskey isn't a good idea as everyone knows it is broken
18:36:34 <JF> GL: OK, so I will file a larger bug, with accesskey being but one example
18:38:35 <JF> JS: we should discuss what to do about other things we've not addressed yet
18:38:53 <JF> MC: there remains interactive elements, and some comments about landmarks as well
18:39:22 <janina> scribe: janina
18:39:38 <janina> cs: I'm assigned other sections to find reviewers, I expect to get some done, probably not all
18:42:10 <JF> JS: we could ask for an extension
18:43:01 <JF> CS: what about people just filing bugs and not tagging them with the TF tag
18:43:19 <JF> JB: we will likely need a quick hour or so before end of biz on the 3rd
18:43:26 <janina> discussion on how to deal with reviews we know arecoming
18:43:55 <JF> suspect that we could do what Cyns suggested - file bugs as individual bugs and then review later to add the TF tag
18:45:16 <JF> JS; what we are saying then is for any further reviews ask that bugs also be filed
18:45:37 <JF> and then MC and JS will watch them and make sure nothing  slips
18:46:22 <JF> MC: in the past week there were 35 a11y bugs, and of those 21 are tagged a11yTF
18:47:05 <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
18:50:16 <JF> [discussion of next steps and when/if we meet again before midnight wednesday]
18:51:07 <MichaelC> topic: Landmarks
18:51:09 <MichaelC> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Landmarks
18:51:17 <JF> JS; we will meet again on Wednesday Aug. 3 @ 5:30 PM boston time for 1 hour
18:52:52 <JF> 4.13.2 Bread crumb navigation - Leonie should file a bug
18:53:52 <JF> [explaining what a tag cloud is for some attendees]
18:54:23 <JF> CS: there is no tag-cloud element. the spec explains why a tag-cloud element was not created
18:56:56 <JF> CS: perhaps these should be removed from the spec, and simply provide a list of things not addressed
18:57:12 <JF> CS: we should file a bug to remove this from the spec
18:57:25 <JF> we either need to fix the examples or remove the section
19:01:30 <MichaelC> topic: Interactive Element
19:01:32 <MichaelC> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Interactive_Elements
19:04:59 <JF> GL: Facilitate grouping of menu items 
19:06:45 <JF> Recommendation: The HTML5 specification should note that user agents may override the default presentation described in order to comply with user preferences.
19:06:46 <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. 
19:09:34 <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/
19:12:54 <Zakim> -JF
19:12:55 <janina> scribe: janina
19:13:22 <Zakim> -Judy
19:14:50 <Zakim> -Katie_Haritos-Shea
19:14:53 <Zakim> -Cynthia_Shelly
19:15:40 <MichaelC> topic: Global issues
19:15:42 <MichaelC> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/Miscellaneous
19:26:20 <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? 
19:26:20 <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 .
19:26:33 <janina> Greg to file bug on providing a method for user agent to declare AT in use
19:26:50 <janina> Greg also to file a bug noting there are privacy concerns with the former, and also
19:27:07 <janina> that there are privacy concerns around inferring dsability from tracking events
19:27:39 <janina> We will pass these concerns also to the new W3C privacy WG
19:33:11 <Zakim> -Greg
19:33:14 <Zakim> -Michael_Cooper
19:33:15 <Zakim> -Janina_Sajka
19:33:16 <Zakim> WAI_PF(A11Y)11:00AM has ended
19:33:18 <Zakim> Attendees were Greg, Michael_Cooper, Judy, Janina_Sajka, Cynthia_Shelly, +44.207.391.aaaa, Lynn_Holdsworth, kford, JF, Katie_Haritos-Shea, Steve_Faulkner, Rich_Schwerdtfeger,
19:33:21 <Zakim> ... Laura_Carlson
19:33:53 <MichaelC> rrsagent, make minutes
19:33:53 <RRSAgent> I have made the request to generate http://www.w3.org/2011/08/01-html-a11y-minutes.html MichaelC
19:40:01 <janina> zakim, bye
19:40:01 <Zakim> Zakim has left #html-a11y
19:40:07 <janina> rrsagent, make log public
19:40:15 <janina> rrsagent, make minutes
19:40:15 <RRSAgent> I have made the request to generate http://www.w3.org/2011/08/01-html-a11y-minutes.html janina
19:42:11 <MichaelC> chair: Janina_Sajka
19:42:15 <MichaelC> trackbot, end meeting
19:42:15 <trackbot> Zakim, list attendees
19:42:16 <trackbot> RRSAgent, please draft minutes
19:42:16 <RRSAgent> I have made the request to generate http://www.w3.org/2011/08/01-html-a11y-minutes.html trackbot
19:42:17 <trackbot> RRSAgent, bye
19:42:17 <RRSAgent> I see no action items