RE: Minutes for 26 September UAWG Meeting

I had 2 actions from the call on Thurs:

(1) Jan to refine the definition of Documentation to rule out the conformance claim, user forum questions, etc. (#891)

PROPOSAL (based on ATAG2.0, but with a new note):
Documentation: Any information that supports the use of a user agent. This information may be provided electronically or otherwise and includes help, manuals, installation instructions, tutorials, etc.
Note: The level of technical detail in documentation for users should match the technical level of the feature. For example, user documentation for a browser's zoom function should not refer users to the source code repository for that browser.

EXISTING:
Documentation: Any information that supports the use of a user agent. This information may be found, for example, in manuals, installation instructions, the help system, and tutorials. Documentation may be distributed (e.g. as files installed as part of the installation; some parts may be delivered on CD-ROM, others on the web).
(http://www.w3.org/WAI/UA/2013/ED-UAAG20-20130925/#def-documentation) 



(2) Jan to update the Intent of the IER of 3.3.2 to try to address greg's concerns in http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0111.html. (#892)

PROPOSAL (adapted from ATAG2): 
Intent: Some users with disabilities will need help in determining how to use the accessibility features that user agents provide. There are four possibilities:
(a) This information can be provided in the documentation of the user agent (e.g. help system, context sensitive help, etc.);
(b) The user interface element is self-explanatory (e.g. a zoom % drop-down menu);
(c) The accessibility feature is actually a service of the platform (e.g. high contrast mode), which therefore has the responsibility to document the feature; or
(d) The feature is not used directly by users (e.g., passing information to a platform accessibility service). In this case, user documentation does not make sense, although developer documentation (e.g. how accessibility APIs are used, the user agent's own plug-in API) would still be recommended.




> -----Original Message-----
> From: Richards, Jan [mailto:jrichards@ocadu.ca]
> Sent: September-26-13 2:33 PM
> To: WAI-UA list
> Subject: Minutes for 26 September UAWG Meeting
> 
> Minutes:
> http://www.w3.org/2013/09/26-ua-minutes.html
> 
> Full text:
> WAI UA
> 
> 26 Sep 2013
> 
> Agenda
> 
> See also: IRC log
> 
> Attendees
> 
> Present
> Jeanne, Greg_Lowney, +1.425.883.aaaa, Kelly, Jan Regrets Jim_A., Kim_P.
> Chair
> Kelly Ford
> Scribe
> Jan
> Contents
> 
> Topics
> Update on publishing Last Call
> proposals for 3.3.2
> proposals for 1.4
> >From timely final tweaks before Last Call
> EO comment 2010?
> Summary of Action Items
> <kford> trackbot start meeting
> <trackbot> Meeting: User Agent Accessibility Guidelines Working Group
> Teleconference <trackbot> Date: 26 September 2013 <scribe> Scribe: Jan
> Update on publishing Last Call
> 
> JS: A complaint was filed to Judy that we were violating Process by going to
> last call without addressing text customization ... Met with Judy about this ... I
> proposed we go to last call then work on the text customization piece ... But
> might cause a third last call ... Discussed with chairs ... I couldn't guarantee
> how long it would take ... If it will take longer than a month to add these
> pieces, we should be ok to go to last call regardless.
> ... So now, I'd like to look at what would be straightforward to do and what
> might take longer.
> 
> Attachment: http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/att-
> 0116/implementing-uaag-text.html
> 
> <scribe> ACTION: Jeanne to mark changes up into a new draft using 'new'
> and 'remove' styles (including the Intent of 1.4 even though that section
> doesn't match our current style). [recorded in
> http://www.w3.org/2013/09/26-ua-minutes.html#action01]
> <trackbot> Created ACTION-888 - Mark changes up into a new draft using
> 'new' and 'remove' styles (including the intent of 1.4 even though that
> section doesn't match our current style). [on Jeanne F Spellman - due 2013-
> 10-03].
> GL: I'm about 2 thirds of the way through this stuff and will send comments
> soon.
> 
> proposals for 3.3.2
> 
> JS: Was working on it, but not sure what the final decision was
> 
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0113.html
> 
> <scribe> ACTION: Jeanne remove or renumber "See guideline 5.3 for
> information about documentation." [recorded in
> http://www.w3.org/2013/09/26-ua-minutes.html#action02]
> <trackbot> Created ACTION-889 - Remove or renumber "see guideline 5.3
> for information about documentation." [on Jeanne F Spellman - due 2013-10-
> 03].
> GL: Also table of contents needs fixing
> 
> <jeanne> ACTION: jeanne to review table of contents and links [recorded in
> http://www.w3.org/2013/09/26-ua-minutes.html#action03]
> <trackbot> Created ACTION-890 - Review table of contents and links [on
> Jeanne F Spellman - due 2013-10-03].
> <Greg> Technically, if the conformance claim is on the web, couldn't
> someone claim that it counted as documentation, just as much as Knowledge
> Base entries on their web site?
> <scribe> ACTION: Jan to refine the definition of Documentation to rule out
> the conformance claim, user forum questions, etc. [recorded in
> http://www.w3.org/2013/09/26-ua-minutes.html#action04]
> <trackbot> Created ACTION-891 - Refine the definition of documentation to
> rule out the conformance claim, user forum questions, etc. [on Jan Richards -
> due 2013-10-03].
> <Greg> Just to be clear, I would not veto the previously proposed wording,
> even though I feel it has potential loopholes.
> <Greg> It should be fine to put a note in the Implementing document that
> provides general guidance on what is and isn't within the spirit of the
> requirement.
> <Greg> Or maybe put the Note under the definition of Documentation.
> <Greg> My original comments are at
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0111.html.
> <Greg> They're also beneath your reply.
> <scribe> ACTION: Jan to update the Intent of the IER of 3.3.2 to try to addess
> greg's concerns in http://lists.w3.org/Archives/Public/w3c-wai-
> ua/2013JulSep/0111.html. [recorded in http://www.w3.org/2013/09/26-ua-
> minutes.html#action05]
> <trackbot> Created ACTION-892 - Update the intent of the ier of 3.3.2 to try
> to addess greg's concerns in http://lists.w3.org/archives/public/w3c-wai-
> ua/2013julsep/0111.html. [on Jan Richards - due 2013-10-03].
> proposals for 1.4
> 
> JS: That's my stuff from above
> 
> <jeanne> http://lists.w3.org/Archives/Public/w3c-wai-
> ua/2013JulSep/0110.html
> >From timely final tweaks before Last Call
> 
> JS: I was doing Greg's tweaks
> 
> <jeanne> http://www.w3.org/WAI/UA/UAAG20/#sc_188
> JS: And I got down to 4. Re Split of 1.8.1 and 1.8.x Customize Highlighting
> 
> If we decide to keep 1.8.x, it should be reworded because the agreed-upon
> wording does not work when taken out of context (i.e. it talks about
> highlighting, not about highlighting viewports). It should be changed to
> something like "When highlighting viewports as specified by 1.8.1 Highlight
> Viewport, highlighting options include at least" (which parallels the wording
> of 1.3.2, Highlighting...
> 
> scribe: Options).
> 
> 4. In the chat of 2013-07-18 I'd suggested that we add to 1.3.2 "(d) shape and
> size when the indicator is an image", but it was at the very end and we didn't
> end up discussing it.
> 
> 5. If we don't merge 1.8.x into 1.3, I suggest adding to 1.3.2 an additional list
> item, "blink rate, where blinking is implemented", thus paralleling the fact
> that blinking is referenced in 1.8.x.
> 
> JR: Not sure about "shape"
> 
> <Greg> Yes, Jan, I can see that "shape" could be confusing. I was thinking of
> the different images (e.g. replacing Google's bunch of balloons with another
> image), but that's not clear.
> <Greg> We could say "image"?
> <Greg> Or drop that and just use size? But would color perhaps be a a
> problem, e.g. dark image when the user changes to dark background?
> JR: Could we just keep at size?
> 
> <Greg> Dropping to size would be okay.
> <Greg> (Changing images--sprites--is no more difficult than changing your
> user's profile image, etc.) <Greg> Dropping to size would be okay.
> (d) size, when the indicator is an image
> 
> JR: GL's proposal was 1.8.8 When highlighting viewports as specified by 1.8.1
> Highlight Viewport, highlighting options include at least
> 
> <Greg> The proposed change to that is based on the wording of "1.3.2
> Highlighting Options: When highlighting classes specified by 1.3.1 Highlighted
> Items, the user can..."
> <jeanne> http://www.w3.org/WAI/UA/2013/ED-UAAG20-
> 20130925/MasterUAAG20130925.html
> <jeanne> http://www.w3.org/WAI/UA/2013/ED-UAAG20-
> 20130925/MasterUAAG20130925.html#sc_188
> <Greg> Re 1.8.8, we want to say something like "where applicable", as we
> don't want to imply they have to add blinking, only make it adjustable where
> it's implemented, right?
> <Greg> Even things like stroke width don't always apply--it can be highlighted
> just by inverting the colors, for instance.
> JR: And remove "shape"
> 
> <Greg> Does this apply only to graphical viewports?
> 1.8.8 Customize Viewport Highlighting:
> 
> When highlighting viewports as specified by 1.8.1 Highlight Viewport,
> highlighting options include at least: (Level AA)
> 
> size
> 
> color
> 
> stroke width (where implemented)
> 
> blink rate (where implemented)
> 
> <Greg> Does the proposed wording require they allow increasing the size of
> the highlighted title bar of the active window?
> JR: Should "stroke width" be "borders (color, style, thickness)" from 1.3.2?
> ... OK to remove "size"
> 
> <Greg> I'm a little confused over what is and isn't
> required/allowed/expected by 1.8.8, and what's used today.
> <Greg> Often the active viewport is today highlighted only with a keyboard
> focus indicator--is that enough, or not?
> <Greg> Presumably it's not as much as we'd like.
> <Greg> So having the viewport contain a text cursor that is customizable,
> good enough or not? I think it does not meet the intent.
> <Greg> Color is *always* foreground and background.
> <Greg> Changing one or the other leads to invisible text.
> <Greg> Not necessarily of the entire contents, but of the border, title bar,
> etc.
> <Greg> In this case.
> <Greg> The UA should not have to allow choosing between many different
> highlighting mechanisms, but we may want to define a minimum, and say
> that any attributes it uses should be customizable.
> JR: Not sure example in 1.8.1 is of a viewport...its highlighting controls
> 
> <Greg> That is, we don't want to require changing color of the content of the
> active viewport, but if the UA provides that option it must allow changing
> both foreground and backgroun.
> <Greg> Similarly we don't require highlighting with a border, but if it provides
> that, it must allow changing color and thickness of that border.
> <jeanne> When highlighting viewports as specified in 1.8.1, the highlighting
> mechanisms must be customizable When highlighting viewports as specified
> by 1.8.1 Highlight Viewport, the highlighting mechanism must be
> customizable (e.g., blink rate, border style).
> 
> <Greg> "the user can customize attributes of the highlighting mechanism"?
> To try to avoid implying that we require choosing additional mechanisms.
> <Greg> "(e.g. blink rate for blinking, color and width of borders)"
> 1.8.8 Customize Viewport Highlighting: The user can customize attributes of
> the viewport highlighting mechanism (e.g., blink rate, border style).
> 
> 1.8.8 Customize Viewport Highlighting: The user can customize attributes of
> the viewport highlighting mechanism (e.g. blink rate for blinking, color and
> width of borders).
> 
> <Greg> Oops, you lost the reference to 1.8.1.
> 1.8.8 Provide Viewport Highlighting Options: The user can customize
> attributes of the viewport highlighting mechanism (e.g. blink rate for blinking,
> color and width of borders).
> 
> <Greg> Looks good! (Once the list is removed).
> JS: 1.8.8 Customize Viewport Highlighting: When highlighting viewports as
> specified by 1.8.1 Highlight Viewport, the user can customize attributes of
> the viewport highlighting mechanism (e.g. blink rate for blinking, color and
> width of borders). (Level AA)
> 
> <Greg> Did you want to keep thickness as a border attribute?
> <Greg> I left that out.
> <Greg> Sorry, "style".
> <Greg> Okay to leave out of the SC itself, can be in examples.
> <Greg> Jan, did you agree with my proposals?
> JR: We are finished Greg's comments re: 1.8.8
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0110.html
> 
> <Greg> I think the whole "style" thing was about choosing solid over dotted,
> etc., but probably fine.
> <Greg> Jan, did you review and agree with my other proposals in the email,
> the ones Jeanne had no questions about?
> JS: Looking at some others...
> ... 1.6.5 def can add those phrases to the intent
> 
> EO comment 2010?
> 
> JS: Jim and I need to look back into 2010 to see what the reolutions were.
> 
> Summary of Action Items
> 
> [NEW] ACTION: Jan to refine the definition of Documentation to rule out the
> conformance claim, user forum questions, etc. [recorded in
> http://www.w3.org/2013/09/26-ua-minutes.html#action04]
> [NEW] ACTION: Jan to update the Intent of the IER of 3.3.2 to try to addess
> greg's concerns in http://lists.w3.org/Archives/Public/w3c-wai-
> ua/2013JulSep/0111.html. [recorded in http://www.w3.org/2013/09/26-ua-
> minutes.html#action05]
> [NEW] ACTION: Jeanne remove or renumber "See guideline 5.3 for
> information about documentation." [recorded in
> http://www.w3.org/2013/09/26-ua-minutes.html#action02]
> [NEW] ACTION: Jeanne to mark changes up into a new draft using 'new' and
> 'remove' styles (including the Intent of 1.4 even though that section doesn't
> match our current style). [recorded in http://www.w3.org/2013/09/26-ua-
> minutes.html#action01]
> [NEW] ACTION: jeanne to review table of contents and links [recorded in
> http://www.w3.org/2013/09/26-ua-minutes.html#action03]
> 
> [End of minutes]
> 
> 
> 
> 
> 
> 
> 
> Cheers,
> Jan
> 
> (MR) JAN RICHARDS
> PROJECT MANAGER
> INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
> OCAD UNIVERSITY
> 
> T 416 977 6000 x3957
> F 416 977 9844
> E jrichards@ocadu.ca
>

Received on Friday, 27 September 2013 21:13:06 UTC