Andrew: may be possible to join part of the California face to face via teleconference
Shawn: If you are able to participate please indicate what times you will joining be at local time in Santa Clara
<shawn> Availability for Upcoming EOWG Teleconferences [including during the face-to-face]: http://www.w3.org/2002/09/wbs/35532/availability/ please answer "2 November 2009 Face-to-Face" and "3 November 2009 Face-to-Face"
<shawn> EOWG Face-to-Face Meeting page: http://www.w3.org/WAI/EO/2009/11f2f
<shadi> http://www.w3.org/WAI/demos/bad/draft/2009/
shadi: asked people [a while back] to review and provide comments. These have been worked on. The demo pages are pretty final. Just have issue with linking and style across the entire resource. There is a same look and feel but they are still working on the navigation. Welcomes comments and thoughts but no new major features.
william: Home page says "show annotations" but nothing happens when the link is clicked
Shadi: annotations have not been populated yet
andrew: Please look and make suggestions
shadi: We do have a wish list so please keep suggestions coming.
pierre: Did you take into account elderly usability needs or just follow WCAG?
shadi: Did look at requirements of older people. Specifically WCAG techniques that overlap with the needs of older people identified from the literature
<shadi> http://www.w3.org/WAI/EO/2005/Demo/waiage
pierre: Is the user requirements list a general list for older people
william: It came from study
<shadi> http://www.w3.org/WAI/WAI-AGE/comparative.html
shadi: These are not a new set of guidelines that should be used, but we identified that by implementing WCAG 2.0 we can meet these needs.
andrew: The temporary documents sometimes have a longer life than expected
andrew: Need for this became apparent during the literature survey where usability issues were highlighted. Shawn has now produced a requirements document for this.
<shadi> http://www.w3.org/WAI/EO/changelogs/cl-accessibility-n-usability
shawn: Any comments and feedback on the Purpose, Goals and Objectives?
suzette: Should legal part of accessibility be at the top? e.g. how accessibility relates to discrimination laws
william: We should add the message that if you do testing for accessibility you are simultaneously doing it for usability
Shawn: looking at the Audience and Messages section.
william: "help them understand that usability issues should not be included in most accessibility standards" Not sure if this is important to point out and whether it is true
shadi: maybe to help them to define the scope of accessibility
william: "should not be included" sounds like it's optional.
<shawn> "help them understand the scope of accessibility standards, and where general usability might not fit" ?
shadi: Agrees with Shawn that we
may need another bullet point. There is good usability we need
to promote but not under the banner of accessibility
... prefers the word requirements to standards
andrew: Some things are good for everybody. Some are good for specific user groups. We should try and tease those apart a little bit
shawn: Let's keep it more general
for now.
... any other thoughts on audience and messages
shadi: This is a broad spectrum audience. Have we thought of having primary and secondary?
shawn: If you are a web designer and/or developer then the distinction between accessibility and usability doesn't matter as you should care about involving users.
shadi: Seen cases where people are misusing accessibility requirements for usability problems. Wonders if designers are aware how different standards work together.
william: Usable accessibility raises the spectre that there may be unusable accessibility
andrew: This is mentioned in the list of questions.
shadi: Still not sure who are our primary primary audience.
suzette: Would have grouped who developed the standards with the people doing procurement as they often need to know what the accessibility requirements are
shadi: some researchers put standards out there which may do more harm as it causes fragmentation.
helle: should we mention the UN convention to emphasise the need for accessibility?
shawn: Will keep that in mind when drafting the document. Any other thoughts please send via email
andrew: How might we weave WCAG 2's POUR into some of it?
<shadi> http://www.w3.org/WAI/EO/changelogs/cl-impl-users.html
andrew: Look through the Scope, Purpose and Audience to see if we are focused enough.
... Look at Purpose, Goals, Objectives first
william: Another rationale is to reduce inaccessibility feedback (and law suits)
andrew: comments on Audience
shadi: mention web developers (designers, content authors, etc.) Should we emphasise designers in the general sense. Also, designers as in those who do the coding and project managers. These are the two most affected
shadi: Content authors should be removed
william: Does web developers imply those who are developing the architecture of the Web rather than websites
shadi: Worth noting standards developers in the secondary audience
Helle: You have website purchasers and managers. When you're making requirements, before putting out to tender, we should include them as they need to put accessibility into their requirements
andrew: was thinking purchasers are the people putting out the proposal
shadi: Add procurers in the same group as managers
michael: want to remove content authors?
shadi: At least from the primary audience
michael: Thinks content authors are a target group. Even if you have a good template they can destroy everything without having accessible content. Eg copying and pasting content from word into the content management system
shadi: We should keep a note of
this
... but watch not to build everything into one document
andrew: Usability professionals
are not a key audience but may find it useful
... Bearing in mind not wanting to put everything in this
document, let's look at the scope
william: Not sure that "cover details on involving users in every aspect of the 'development lifecycle'" is a 'will not' bullet
andrew: if we focus on that we may produce a book
<Zakim> shawn, you wanted to suggest "comment on just a few key points, e.g. some key parts of the development process with examples" be only important points (e.g., where people are likely to get it wrong)
shawn: suggests that "comment on just a few key points..." we identify where people are likely to mess up and provide some pointers to help them get it right.
andrew: Need to make sure we get across that developers use diverse set of average users.
[Helle commented that disability groups in Denmark like to be involved in sourcing users]
shadi: Going to a disability
organisation may mean you only get specific user groups.
However, it may be difficult to address this problem in the
document.
... a key message should be that you need to be aware of what
you are trying to achieve before approaching an organisation or
individual.
helle: agrees with shadi
michael: If you're conducting user testing then you need to prepare, which can be complex. We should have a note that you can do it yourself in a simple way or get professionals. Any more detail than a note would be too much for this document.
shadi: You can do a lot by yourself but we have to acknowledge that usability testing is a profession.
shawn: usability testing is just part of usability. people with disabilities should be included from the beginning of the design process. ideally as part of a user-centered design process, including usability goals, personas, etc.
<shawn> Notes on User Centered Design Process (UCD) http://www.w3.org/WAI/redesign/ucd
andrew: Send any thoughts and comments on the scope to the group
<shadi> http://www.w3.org/WAI/EO/changelogs/cl-adapt-strat.html
shadi: users sometimes aren't aware of accessibility features they can use. This document helps users identify these features.
andrew: Not sure if Trainers and supporters are primary or secondary audience
shadi: From an impact perspective they are primary as they are the people printing and distributing document. However, the people we're really trying to talk to are the end users.
andrew: writing for the end user but keeping in mind the trainers.
Michael: Can be difficult to reach people who are targeted by this document.
alan: This is what people like to put on their accessible page of their Website but don't do it properly. We could try and get people to point to this instead.
<shawn> [Shawn preparing for promotion of these documents!]
shadi: Not sure if Websites will link to this document but it can be used as a training resource
<achuter> compare with http://www.w3.org/WAI/changedesign
william: Aren't we faced with the problem of "to learn how to use the Web you have to use the Web"
shadi: Trainers and supporters will be key for this document but in terms of language we should target users
michael: Browser manufacturers are a target group as a distributor of the technology who can reach users.
shadi: Lets consider the outline for the document itself
... Title is working title
<shadi> http://www.w3.org/WAI/EO/Drafts/adaptive/strategies.html
shadi: Should we reword the title? A bit long and adaptive strategies is a bit scary. Trying to use words such as additional tools and customise instead. Note that this is not step by step guides but point out what you can do.
<shawn> +1 to rethinking title
Shawn: Wonders if we want this document to focus on strategies that people with minor or age-related disabilities are likely to use as opposed to a lot about screen readers.
shadi: trying to tone the document so people can see what they can do with their own system and then if they need to go to the assistive technologies. Some people may not even get to the Using Additional Tools section
<achuter> I think it should make people aware what assistive technology is available, but not how to use it.
andrew: Capturing some tools/plugins that can make configuring the browser easier.
No actions recorded
[End of minutes]