How People with Disabilities Use the Web

<Shawn> How People with Disabilities Use the Web - discuss section headings of Accessibility Requirements (see comparison with WCAG 2.0 At a Glance)

<Shawn> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/provisions#toc

<Shawn> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/provisions#comparison

Shawn: Specifically, let's discuss the section headings
... we talked about organizing these roughly along the lines of WCAG2 and along the lines of WCAG 2 At A Glance. Here is a comparison showing what is different between them.
... First is Text alternatives for non-text content. Same as WCAG2 without the imperative.

Sharron: I like dropping the imperative.

<Andrew> +1

Shawn: Next in WCAG2 at a Glance is audio-video content...

Jennifer: Motion to accept.

Shawn: I guess my only question is...is it too vague?

Andrew: Well, there is detail later on, within the paragraph.

Shawn: Accepted then.
... skip next one about Adaptable and return later on.

<Shawn> Let's look at Distinguishable: Make it easier for users to see and hear content including separating foreground from background.

Shawn: On to sufficient contrast to make content easy to see and hear

Shadi: For consistancy we should keep the word "content"

<Shadi> ACTION: Shadi - accessibility requirements - keep "content" rather than "things" in "Sufficient contrast to make content easy to see and hear" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action01]

Jennifer: I have no background on WCAG2 at a Glance, why was "things" chosen in the first place?

<Shawn> ACTION: Shawn - at a Glance - consider "Use sufficient contrast to make [things]{content} easy to see and hear" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action02]

Shawn: Trying to keep it less jargony. But have previously used "content"
... next under Operable, WCAG2 at a Glance said make all functionality keyboard accessibile, this one has slightly different wording.

Jennifer: Content and function "are" rather than "is".

<Shawn> Keyboard Accessible: Make all functionality available from a keyboard.

Shawn: Well, the guideline actually only mentions functionality, so is it pushing it to add content?

Jennifer: Seems fine to me to add content and make it like it reads in WCAG2 at a Glance

Shawn: Thoughts about the fact that content is not in the Guideline itself. My feeling is that unless there is a really strong reason, its better not too.

Andrew: Clicking on a link for example, is not thought of as functionality, so wanted to be sure that it was inclusive of people's understanding

Shawn: Worth adding if not in Guideline?

<Shawn> Functionality is available from a keyboard.

Shadi: Some may not think of their blog or non-dynamic site as having functionality. This was to let people know that even without fancy widgets, content must be reachable.

Shawn: As long as content underneath makes reference clear, maybe not add content since not in Guidelines
... can we make it clear in the discussion?

<Shadi> ACTION: Shadi - accessibility requirements - keep "functionality is accessible by keyboard" (remove "content") and explain applicability early in the description [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action03]

Shawn: and you added word accessible when the original was available

<Shawn> Keyboard Accessible: Make all functionality available from a keyboard.

Shawn: comments?

Liam: but why say it twice?

<Shawn> Functionality is available from a keyboard. OR Functionality is accessible by keyboard.

Ian: Accessible by keyboard sounds better to me but perhaps because I am used to it.

<Shadi> [[functionality is available from keyboard]]

Shawn: Accessible may trigger the thought it is only for disability, available implies power users as well, a ggo thing!.

<Shawn> ACTION: Shawn - at a Glance - consider "Functionality is available from a keyboard." [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action04]

Shadi: Yes available is more in line with guidelines as well.

<Shadi> ACTION: Shadi - accessibility requirements - change "functionality is accessible by keyboard" to "functionality is available from keyboard" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action05]

Sharron: to keyboard

Ian: via keyboard

<Shawn> "functionality is available via keyboard

<Shawn> WCAG: "Keyboard Accessible: Make all functionality available from a keyboard."

Shadi: stumbling over a keyboard, technically it is a keyboard interface.

Shadi: rather keyboard controls can access the functionality

<Shadi> ACTION: Shadi - accessibility requirements - change "functionality is accessible by keyboard" to "functionality is available from a keyboard" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action06]

Shawn: OK, Operable: users have sufficient time
... question is should we change from "enough time" to "sufficient time"

<Shawn> wcag: Enough Time: Provide users enough time to read and use content.

Shadi: I thought "enough" was a bit too casual, it's a personal preference.

Shawn: WCAG says "enough" What about using "sufficient in write-up?

Liam: Is there an advantage to a more formal tone?

<Shadi> ACTION: Shadi - accessibility requirements - change "Users have sufficient time to read and use the content" to "Users have enough time to read and use the content" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action07]

Shawn: Let's go with consitency to WCAG2 and use enough with sufficient in following discussion

<Shawn> wcag 2: 3 Seizures: Do not design content in a way that is known to cause seizures.

Shawn: Proposal is to add "hazards". What other hazards are there?

Liam: You should not have risk of siezure. So if in testing no one actually has a seizure - some may think great, no problem!

<Shawn> content does not risk causing seizures

Shadi: Just to clarify to reader, it is a real threat and even when does not go all the way to actually causing seizure, flickering content can cause migraines or other problems.
... but am happy to be more discriptive in follow on discussion and leave consistency to WCAG2

Liam: WCAG's format is basically saying don't do this because there is good evidence.

Shawn: Yes, it says "in way that is known to cuase..." and we were trying to shorten it.

<Shadi> [[Content is known not to cause seizures]]

Shawn: do we want to keep in this simplified, tersified version?

Shadi: What about "content is known not to cause seizures"

Andrew: I like the shorter, to the point version.

Shawn: I would have thought as a designer I would have to do a whole bunch of tests to confirm.

Liam: Is function other than content, by the way?

Shawn: That is a tangent.
... our goal is to take wording of WCAG2 and just shorten it for our purpose.

Shadi: But this may not be specific to WCAG2 alone. For example an authoring tool. This is actually intended to be more general than WCAG2

Shawn: Point taken.
... more on the seizures discussion, or go with short and sweet?

<Shawn> Navigable: Provide ways to help users navigate, find content and determine where they are.

<Shadi> ACTION: Shadi - accessibility requirements - change "Content does not cause seizures or hazards" to "Content does not cause seizures" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action08]

Shawn: Next one is Navigable

<Shawn> Navigable: Provide ways to help users navigate, find content and determine where they are.

<Shawn> Users can navigate, find content, and determine where they are

Shawn: At A Glance says users can navigate and find content and determine where they are
... adding "and determine where they are" was not in At A Glance, any objection to adding it here?
... no objection. Next Shadi?

Shadi: It's changed slightly from users are helped to users can do it.

<Shawn> Help users navigate...

<Shawn> Users have help to navigate, find content, and determine where they are.

Liam: There is a sense change there. Difference between providing help and just knowing they can eventually get there no matter how difficult.

<Shawn> Users are helped to navigate, find content, and determine where they are

<Andrew> Users are helped to navigate ...

Liam: Help users to navigate?

Shawn: Non-imperative voice, however

<Shawn> There is help to navigate, find content, and determine where they are

<Shadi> [[Users are helped to navigate, find content, and determine where they are]]

Liam: Navigation aids are available.

<Shadi> [[Users have help to navigate, find content, and determine where they are]]

Liam: is this the difference between Skip Link and no Skip Link?

Shawn: Users have help to...

<Shawn> Content helps users to navigate, find content, and determine where they are

Andrew: This implies that help could come from outside.

<Shawn> Content helps users navigate, find content, and determine where they are

<Shawn> [Website, web tool] helps users navigate, find content, and determine where they are

Liam: the website helps users...

<Shadi> [[Help for users to navigate, find content, and determine where they are]]

Shadi: Maybe I will take it off line following that last suggestion

<Andrew> [[Help is provided for users to ...]]

Shawn: Could be interpreted to mean Help system through online help, etc. It is very much NOT that.

<Shawn> [[[ caution: avoid wording that sounds like it's a separate help system ]]

<Shawn> Users can easily navigate, find content, and determine where they are

Liam: The intent is for it to be easy, straight forward.

Shawn: Any objections to adding easily for now?

Sharron +1

<Shadi> ACTION: Shadi - accessibility requirements - change "Users can navigate, find content, and determine where they are" to "Users can easily navigate, find content, and determine where they are" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action09]

Shawn: Next point is a simple addition of content as opposed to text

<Shawn> wcag Readable: Make text content readable and understandable.

<Shawn> {Content is} readable and understandable

<Shadi> ACTION: Shadi - accessibility requirements - consider "users are helped to..." approach from WCAG in "Users can easily navigate, find content, and determine where they are" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action10]

<Shawn> Make text readable and understandable

Shawn: Thinking was that "text" was less jargony than "content"

<Shawn> suggestion: Text content is readable and understandable.

Liam: Are we changing meaning by using "content?"

Shadi: It's the idea of content being something different than only text

Liam: Does it exclude alt-text?

Shawn: No

Liam: Then "content" is preferable

Sharron +1 for content

Shawn: Is there a strong reason to deviate from WCAG2 wording?

<IanPouncey> Another +1 for content

Shawn: It's all about the words

Andrew: Also about text justification and some lay-out consderations

<Andrew> +1 for just 'content'

<Shawn> [Shawn looks at atag 2 & uaag 2...]

Liam: Using "text content" excludes other kind of content.

Shawn: That is the focus of WCAG2, but this document is meant to be more broad.

Andrew: Simple language

Liam: Understandable

Shawn: While Success Criteria specifically focus on text, we want to broaden this document.

<Andrew> yes

<Shawn> ^^ rationale ^^

<Shawn> proposal: Content is readable and understandable.

Shadi: And it does not divert too much from original, only omits one word

<Shadi> ACTION: Shadi - accessibility requirements - keep "Content is readable and understandable" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action11]

Shawn: next is Make content appear and operate in predictable ways.

<Shawn> content appear{s} and {is} operate{d} in predictable ways

Shawn: Content appears and operates...

<Shawn> content appears and operates in predictable ways

Jennifer: Operates is fine

Liam: acceptable

<Shadi> ACTION: Shadi - accessibility requirements - change "Content appears and is operated in predictable ways" to "Content appears and operates in predictable ways" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action12]

Shawn: Last point, "Help users avoid and correct mistakes" change of tone says Users are helped to avoid and correct mistakes.

<Shawn> 3.3 Input Assistance: Help users avoid and correct mistakes.

<Shawn> users {are helped to} avoid and correct mistakes

Liam: What is rationale for passive voice? Why are we removing agency?

Shawn: as discussed earlier, Shadi want to explain?
... all but two can be more simply reworded as simple statement of fact.
... we are conveying an aspect of the web site itself as opposed to giving instructions for designers.

Shawn: We are in "How PWD..." Most reword nicely.

<Shawn> Users can easily avoid and correct mistakes

Shawn: to parallel previous wording, we can say "easily"

Andrew: Not quite the same this time, is it?

<Shawn> users [get|receive] help avoid and correct mistakes

Jennifer: What about "users receive help...?" Had the same thought as Liam

<Shawn> users are helped avoid and correct mistakes

<Shawn> users are helped to avoid and correct mistakes

Liam: Users are helped seems right in this context.

Andrew: Yes

<Shadi> ACTION: Shadi - accessibility requirements - keep "Users are helped to avoid and correct mistakes" [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action13]

<Shawn> 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

<Shawn> at a glance: (Maximize compatibility with current and future technologies)

<Shadi> Content is compatible with different technologies

Shadi: When talking about older people we are also often talking about older technology too.

Liam: Sufficiently meaningful to our readers?

Andrew: Is it any less meaningful than current and future technologies?

Liam: No, but I am thinking about assistive technologies?

<Shawn> Content is compatible with different technologies, including assistive technologies

Shadi: We have suggested that PWD use various devices but also different approaches.

Liam: Don't the rest of the points that we have already covered address those approaches that are not AT?

Shadi: Cross-browser issues, speaking browsers, etc.

Andrew: "Understanding" emphasizes to the point of saying especially.

Shadi: What if we emphasize AT within the text?

Liam: Great

<Shawn> Content is compatible with different technologies, including assistive technologies

<Shawn> Content is compatible with different technologies, especially assistive technologies

Shawn: Is there a reason not to add assistive technologies on there?

Andrew: Just that it makes it longer.

Liam: Given that it will be discussed in the text, it may not need to live in the heading.

Shawn: Editor's discretion. If not in heading, very clear from first sentence? OK?

<Shadi> ACTION: Shadi - accessibility requirements - keep "Content is compatible with different technologies" but consider adding "including assistive technologies" or similar to include ATs [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action14]

Shadi: Keyboard requirement will be only one that has "functionality." Do we want to revisit?

Liam: Maybe see if any of the others should be functionality rather than content.
... or both.
... Did we decide that content included everything/

Shawn: Can we say explicitly that this document includes functionality as part of content?
... if we have both content and functionality in one place and content alone in others, does it imply that we are not referring to functionality everywhere?
... Decision is to take functionality out?

Liam: Are we changing it so that it is then emphasized within the text that functionality is included?

Shadi: Yes, we will clarify early in the text that functionality is included.

Andrew: And then we have a closer match to WCAG wording

Shawn: Basically everywhere else we only use content. If we say content is everything, including functionality, we could use just the word content.

Andrew: But with the keyboard, functionality is critical.

Shadi: Yes

<Shawn> wcag 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout ) without losing information or structure.

Shawn: Back to 1.3 to discuss Adaptable and Wayne's comments

<Shawn> at a glance: (Make content adaptable; and make it available to assistive technologies)

<Shawn> Content can be presented in different ways

<Shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2010JulSep/0025.html

<Shawn> Assistive technology can change perceptual mode or style with no loss of meaning.

<Shawn> Content is adaptable and can be presented in different ways

<Shawn> Content can be adaptable in different ways

Liam: Meaning of content does not rely on visual presentation? separate from layout?

<Shawn> Content is adaptable and can be presented in different ways without losing meaing

Sharron: Don't like different ways - confusing.

Liam: Content is plastic

<Shadi> [[Content can be presented according to preferences]]

<Shawn> users can change the way content is presented without loosing meaning

<Shadi> [[Presentation can be adapted according to preferences]]

Liam: Content has no loss of meaning

Sharron: Content can be variously presented with no loss of meaning

<Shadi> [[Content can be presented differently without losing information]]

<Shawn> [Presentation can be adapted according to users' preferences

Liam: Meaning is independent of its presentation

<Shawn> Users can adapt the presentation of the content

<Andrew> [Presentation of content can be adapted according to users' preferences]

<Shawn> Users can adapt the presentation of the content [then in descriptino = iwhtout lose of information or structure

<Shawn> Users can change the presentation of the content [then in descriptino = iwhtout lose of information or structure

<Shawn> Users can change the presentation of the content [then in description get in "without losing information or structure" and "adaptable" :-]

<Shawn> Users can change the presentation of the content [then in description get in "without losing information or structure" and especially with assistive technologoies - "adaptable" :-]

<Shawn> wcag 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout ) without losing information or structure.

Shadi: Slightly prefer adapt because it is used in many context

Liam: Support adapt is specific to making something more suitable for a particular purpose.

Andrew: Lean toward adapt.

Sharron: Direct reference to WCAG

Shawn: Keep in mind that you can expand within the paragraph. Could say change in heading, expand with adapt in text.

<Shadi> ACTION: Shadi - accessibility requirements - change "Content can be presented in different ways" to "Users can adapt the presentation of the content" but consider "change" as well [recorded in http://www.w3.org/2010/08/13-eo-minutes.html#action15]

Shawn: editor's discretion.

Shadi: OK, will consider both.

Shawn: Want to address Wayne's point in email. There is an issue that Wayne and I are personally feeling about how WCAG2 is being used in the real world. This comment is partly related to that.
... Given the time, let's bring this up again. We have come up with some suggestions for WCAG2 At A Glance. Try to focus, not just on his specific modification, but on the underlying part. While this modification may not be the word-for-word choice, these are important points. Please consider and feel free to respnond on the list.

Andrew: Some of Wayne's comments may be used to inform the emphasis of the paragraph.

Shadi: Yes, it is very helpful. I will see how much I can incorporate.

Shawn: And useful when we revisit WCAG2 At A Glance.

Review of ATAG

Shawn: Feel free to send comments as an individual. Let EO know about your comments.

WAI ARIA Review

Shawn: Last Call will be in next few weeks. If we have Quick Fixes, would be great to get them in now. Will have time to comment again after Last Call, but would be good to do now.
... thinking of big, easy overview things to fix before Last Call would be good.

Training Resource Suite

<Shawn> recent edits: http://www.w3.org/WAI/EO/changelogs/cl-training.html#changes

Shawn: In agenda is the link to recent edits.
... Andrew?

Andrew: In the longer documents, we tried to condense and restructure materials and incorporate editorial comments.
... Presentation has been adapted based on feedback. Thanks to all who commented.

Shawn: There were changes as a result of the questionaire and Jennifer's comments to the editor's list.
... as far as we know the comments have been addressed.
... main substance of the materials have not been changed.
... Question is where do we go from here? We are thinking that we will publish as a public draft for review. Would want it to be in good shape and would like to publish as draft before too long. How much more review is needed?
... How long do you need before we are comfortable with publishing as a draft?

Jennifer: Tried to look again. I will have copy edits and will send to WAI editors. I was not around during development so have not yet made substantive comments. Will do this weekend.

Shawn: Ian and Liam - availability to comment?

Ian: Can do within next week or two or three.

Liam: Let's say by the end of the month.

Shawn: Shadi and Andrew - end of month OK?
... try for Monday the 30th? OK, will send out a message.

<Andrew> end of month is good

Shawn: After Jennifer's comments are made and incorporated will send out notice for review to rest of group.
... Will be sending draft slides around for review. Ian helped with CSS on that - thank you VERY much. Also drafted slides sets for Biz Case and will be updating other pieces.
... other questions or comments?

<Shawn> http://www.w3.org/WAI/EO/2003/template.html#before