Shawn: Welcome Ian!
<Shadi> http://www.w3.org/WAI/users/involving
<Shadi> http://www.w3.org/WAI/eval/users
Shawn: See email for the assigned prep for today's meeting.
... We published these documents within the last few months and received comments, which we acknowledged, and used as the bisis for clarification. Now, we want to look at the specific points that were submitted and determine if we have adequately responded. In some cases, it seems the commenters may have misunderstood what the docusments were supposed to do. Let's review with the question in mind of whether there is a risk for more
misunderstanding by others.
Shadi: I think your latest remark is an important one. For example, the word "users" triggers testing for me. Perhaps the document might need an opening statement about testing.
Shawn: what are your thoughts about what to add to the introduction, to clarify that we are NOT talking about general usability testing?
Shadi: In the first sentence, the one that defines the advantages, but does not define who PWD are. We could add some clarification there to get everyone on the same page.
Shawn: what would that sentence look like?
Shadi: A reference to the fact that involving PWD means to involve real people to learn from them and their experiences. That outcomes will be better if it is done as an integrated part of the process and not to wait for the end and the testing.
Andrew: you have a closing sentence that gets you started on the benefits, could we elaborate that this is not a how to?
Shawn: We do have a how to in the document.
Andrew: But this is not a recipe book, and this tells them this is not a recipe document.
Ian: To contrast that users are people who use the web site, I thought it pretty good.
Wayne: I am wondering abut the danger of generalizing from one or two disabilities. Conclusions from that could lead developers into a bit of a trap. I saw this quite a bit, when I worked with heads of information technology departments. They might consult two or three PWD and then they would declare that their design was successful just because the person could read with JAWS. It might be useful to include something about that.
Shawn: we have a lot in there.
Wayne: But it fairly buried. Isn't it in the second section?
Shawn: That is the benefits section.
Wayne: We should clearly recognize that it is important to keep in mind that various disabilities have different requirements and that having good insight from one or two doesn't work for everybody. That addresses some of the concerns of the email comments.
Shawn: what about a conclusion to
the first point? We can take as an action item to draft a sentence for the
intro explicitly stating that this is about the broader and early involvement of users. That it may be redundent for some but necessary for others.
... Shadi the rough draft of what you said get into the
minutes?
<Shawn> ACTION: Shawn - Involving users - draft sentence for into positioning "involving users" as early in process, not UT - see Shadi's sentence in minutes & first sentence of next section [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action01]
Shadi: the first sentence says (reads) that is what users means. Ok I'll write something.
Shawn: Going back to Wayne's point, do we need to go back into the document, under an H3 (reads) in bold strong and highlighted, then the paragraph, and underneath getting a range of disabilities, et al.
<Shadi> [something along the lines of: "Involving people with disabilities in web project means including users throughout the design and development process to learn from real-world experiences" or such]
Ian: input text, first paragraph? Might fit under the first paragraph involving users, starting carefully consider, move higher up in the document.
Shawn: One issue, one primary thing to highlight. This document is for web developers and project managers, who do not necessarily know how to involve users. We do not want to make it seem so difficult that they get scared away. We want to try to convince them of the value of this. If that is the primary goal of the page, is there an issue with putting the cautions too early?
Wayne: Could phrase it as a smaller disclaimer. While there are benefits, there are some cautions and link them to a longer paragraph. People with usability concerns, they don't know where this lies in their spectrum. The usability concerns will be raised, and a little disclaimer might help them. Are we not talking to them?
Sharron: Your first idea was to remind developers that the experince of any one group will not address all accessibility concerns. Then provide a link to greater detail. A short mild disclaimer near the top about not putting all your accessibility experince eggs in one basket.
Shadi: I am very border line, I hear Sharron and Wayne, but I lean toward not scaring people away. The primary use case is even farther away, basically it simply says - go out and ask the users.
Sharron: It could be problematic to get input from just one group of users. A mild disclaimer avoids the danger, especially as this is geared for non experts on usability. We don't want to send them too far along the wrong path. A mild caution might actually help give them a little more confidence. That they know to use the right tool for the job, not to expect to use a hammer when they need a screwdriver, etc. Make sure they use this as an opportunity for insighand don't end up with expectations that can't be fulfilled.
<Shawn> ACTION: Shawn - Involving users - see if say something in the beginning pointing to the caution (without being scary!) - not over-generalize.... [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action02]
Shawn: Caution in the intro, but
don't make scary. A note for editor.
... Overall anything else?
Sharron: Can we more specifically identify the user groups? Sometimes we include older people, sometimes users with disabilities and sometimes only users, One of the commenters was uncomfortable with that. To me that wasn't a huge problem, but it struck me as worth consideration. Was anyone else struck by that?
Liam: I was struck by that, if you use the shorthand it can be confusing. The document as it stands, seems to be conflating the experince of general users with those of specific user groups. This document is a reference for involving users with accessibility requirements and it might be a better to explain. We are only talking in the document about a subset of users.
Shawn: If we added a sentence in the beginning to say that we are including PWD and older users would it be sufficient for the rest of the references to users?
Liam: I read the comments, and tend to agree. I would be in favor of being explicit that we are discussing the specific involvment of users with disabilities and older users.
Shadi: I am wondering if belongs with the last sentence, where it says reaping... there we could define the users with disabilties.
Ian: I thought the same as well, this page will help you with PWD and older persons as a user group.
Shawn: This page is not about testing. The other page is. Ironically I struggle with a specific reference to PWD and that it is not just about usability testing.
Shadi: If people come with such expectations before they read, then the opening sentence should clearly define the scope.
Shawn: yes this is not just for disability experts, but also about usablity. Take an action to clearly identify users up front. Ian can you say more about what you think is necessary.
<Shawn> ACTION: Shawn - Involving users - see about defining up front that "users" = pwds and older users [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action03]
<Shawn> ACTION: Shawn - Involving users - see about defining up front that "users" = pwds and older users. then can just say "users" throughout [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action04]
Ian: as a general i9t is important to be consistent labeling, and the document is inconsistent in labelling, then define and use that. Only a suggestyion.
Shawn: other overall?
<Liam2> e.g. say users with disabilities and older users... such users... these kinds of users... etc.
Shawn: For involving users in
different kinds of context. In the first document some of these
actions will change some of the content. If we look at the
email replies are there any additional comments to the replies to the first
document? Changes?
... Ok then let's look at the second document. Involving users in
evaluating, including users in testing. Over all comments on that one?
Shadi: To go back, I remember in an earlier iteration we had a link from there to involving PWD we felt this was too early. To consider users while doing edits.
Shawn: That is near the bottom of the page, it may be an issue. Perhaps a reference in the beginning might be more smooth. Anything broadly about involving users in usability? Reactions to our draft comments?
Andrew: The only comment I had, in analyzing accessibility issues, there was a comment that you would need to be an expert. We should probably temper that paragraph a little bit, saying you should try to rather than identify.
Shawn: Shouldn't they identify themselves, or get someone to do that?
Andrew: Maybe that would be how to temper it. Slightly. on the paragraph.
Shawn: It insinuates that you are doing that.
Ian: Try to determine what you need to.
Shawn: If in a large organization, the person sitting down with the users might be a usability professional. In that case, the usability person would say this is an issue, then the technical person would figure out where the problem is. One possibility is that the middle sentence should not be there. We are really saying that when you find a barrier, don't blame the web site, as it might something else.
Ian: Rather than determining which component is important, create a list of things to take note of. The follow up is to review the technology - the hardware and software being used.
Liam: I think you are right that they don't have to be a technician. In many cases people misunderstand. Evaluating, not the technical eval, but you the experience with the technology.
Shadi: Looking at this paragraph from that perspective, this section leaves you hanging a bit. What is identified, not handling mark up properly? does that relate to conformance? A work around? A reader might experince a bit of headscratching...what do I do?
Shawn: provide more guidance?
<LiamM> (n.b. I was commenting on the 'Initial review' section. Sorry!
Shadi: For the long desc attribute, for example, the usual practice is provide a work around for that. But we can say that isn't really a developers problem. We can add a sentence after the bulleted list, that gives next steps depending upon the problems identified. Maybe different kinds of conclusions to draw.
Ian: That's really difficult to do.
Wayne: what about Ian's direction for the observer to be careful to take complete notes from users when they are doing it. The issues taht are identified may be caused by many things. Not necessarily and don't have this person do the initial evaluation.
Ian: To help me recreate it myself.
Shadi: That leads me to a talk, a sentence after the list, that emphsizes the importance of identifying which component is involved in observed problems. Include consideration of the parameters of what kind assitive technologies they were using. Maybe I was confusing the drawing conclusions part. Add some more about different parameters.
Wayne: I agree with Shadi, it is a little mixed up about what you are doing there.
Shawn: There are a lot of different situations. For example a large organization, or a developer getting a PWD to sit down and fix problems. They would need to figure out or get expertise. For analyzing the issue, maybe change to clarify drawing conclusions or expand.
Shadi: I caution about the wording.
<Shawn> ACTION: Shawn - Involving in Eval - "Analyzing Accessibility Issues" section - see comments - maybe need to change this section just as a caution OR need to expand it? maybe delete "For any accessibility problems you identify, determine which components are responsible. " maybe add sentence after list saying... ? (think of bug report) -- think of gathering data VS drawing conclusions [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action05]
Shawn: Maybe to clarify conclusions, or adding data, ...anyting else?
Shadi: In my notes in the initial
review section up near the top. Reading their comments and then
reading the draft response. The comment is that the commenter would suggest
conducting a full review and repairing the errors in the code before
bringing in any users. The comment is in the section on
conducting a prelimenary review. It sounds absolute. We kind of
agree that it is not good to do a full conformance report, but to
leave that open. This involves the scope of users as well.
... do I want to improve the usability? I would clean up the
code issues first, then do a users report. I am wondering saying
something like I'm not sure exactly what to say. where there is
no prior work, there is a good case for a preleminary review,
because the scope of the evaluations are quite different. We
aren't addressing in that section.
Shawn: Do a full conformance review?
Liam: That would likely to mean less work for the development team. Inevitably code errors are easy to fix before user testing.
Shawn: You would get that in a preleminary review. You wouldn't have to do a full evaluation to do that.
Liam: I would anyway.
Shawn: I would do a pass to see if there was nothing explicit.
Doyle: Liam's idea is pretty typical of what people actually do.
Andrew: There is already a page about steps for an initial review, and a reminder to be reasonable and thorough. It's not a conformance issue. If you follow all those steps it would be thorough.
Shawn: Revise it to be open to all situations. You want to find errors before you bother to bring in users. I don't know if we need to make the distiction of whether it is preleminary or full.
<Liam> Solve the problems that you can solve without users before you bring the users in
<Zakim> Liam, you wanted to ask about initial/preliminary
Shadi: Along those lines, the last sentence of that section says a bit more. Open up with before bringing in users, do at least a preleminary review to make a small wording tweak, a minimum rather that a first step.
<Shawn> ACTION: Shawn - Involving Users in Eval - revise "A first step in evaluating web accessibility is conducting a preliminary review of the website to check for any obvious accessibility problems." to be more open to different situations - and watch terminology (intial, preliminary, conformance). maybe move last sentences up (maybe "do at least a preliminar review") [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action06]
Andrew: Yes that's good.
Shawn: Anything else on the draft reply to comments.
<Shawn> ACTION: Shawn - Involving in Eval - first "The For More Information" to match title below [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action07]
Liam: Can I query the point of usability professionals? I would challenge the second sentence, and the third. Looking at the document notes for usability professionals. The second bullet and the third bullet - don't just look at the technical problems. Solved all the technical problems but still have an unsatisfying experience. An examples is that good heading structures are more informative than not so good heading structures, but it is not technically an error.
<Andrew> Also, the order of items and grouping in forms can be more important to pwd than general users.
Shawn: The issue here is two different things. First, you are a general usability person, and you have never done anything with PWD. A user complains it is not an accessible web app. You need to figure out what the barriers are first. Is it useful for this scenario you can do shortcuts basically. And also the scenario usability testing for PWD usabillity.
Liam: yes if you allow them to break up into three sections, they won't do the disability part.
<Liam> if you allow them to separate usability for people with disabilities from accessibility for people with disabilities they won't do the usability portion.
Andrew: Plus one to Liam. I have found exactly the same sort of things. People would do usability testing. But they weren't getting PWD and the disabilities are useful because they wouldn't pick up on the usability at all.
Shawn: Any other thoughts on that? make sure is recorded in IRC.
Liam: Usability should be as
important as disability.
... you could say normal usability you detail the areas with
usability and accessibility stuff.
<Shawn> ACTION: Shawn - Involving Users - reconsider "Note for usability professionals" points - Liam's concern. [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action08]
Shawn: Make a note to meet Liams'
concern. A good point. Anything else?
... I will make these changes, and send a draft for comment. I
assume we won't need to talk about in email. Reply to the
email, probably bring back to discussion unless someone says
they want to bring the issues back for phone discussion.
<Shadi> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/scenarios
Shadi: The scenarios page has been updated. I think it pretty stable now. A total of 8 scenarios, some tweaked or updated. The age-related conditions due to the WAI age project. There were several comments from people who are not usually active in EO. Comments? Think of the scenarios.
Ian: The page deals with adaptive strategies a great deal but doesn't relate temporary disabilities, the user doesn't have an adaptive strategy.
Shadi: what do you suggest?
Ian: All scenarios begin with the problem a user has and how he or she deals with it. But that depends upon your adaptive strategies. So I think it is important to mention people with temporary disabilities. That doe not seem to fit right now. To take RSI, a more common temporary disability, you go back to basic usability - what you need to help most users in most cases.
Shadi: I am not sure how easy that is to address, but it is a good point. There is a mention in the RSI scenario, but that is way too subtle for people to get, sometimes stronger to get than other times. I will take an action to address, but I can't promise I can resolve.
<Shadi> ACTION: Shadi to consider temporary disabilities as part of a scenario (possibly the RSI or maybe mention in the introduction) [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action09]
Shawn: interesting, I'm not sure how it fits. Think about it, but don't feel a need to squeeze it in somewhere. Perhaps it could be included in the overview. In some presentations I do, I talk about different aspects of what happens. Born blind, or becoem blind later in life. We don't talk about those aspects here.
Andrew: The page where disabilities and barriers, like someone who is right handed and breaks that hand might have a lot of issues. It can be stable or changing.
Shawn: Disabilities and barriers page.
Shadi: I'll take an action that if not this page can be in other documents. Part of the response to some of the commenters.
Heather: In IBM learning we have blending learning. Not one particular platform, one scenario students of several people coming into a virtual sessions. How do they navigate and get to sessions and use those. How do those people with online sessions, a huge item, we are dealing with an economy with travel curtailment, using blended learning. A virtual session. Not just one format. How do you help a student?
Shadi: I think an issue of how much can we pack into such a document. We have two others on online learning. A class room session with electronic books to read. This kind of disabilities need accessible tools. Do we need more, if we have several of that sort it would be about the government. The wrong place to put in?
Shawn: The goal is the document would explain how PWD use the web.
Wayne: we have 400,000 people taking online classes now or blended classes in the CSUs. That consists of a quarter of all classes.
Heather: I know there is a huge gap out there. It is the field I am currently working in. A missing gap. How people access that kind of learning.
Shawn: How do the existing scenarios the online student not meet or provide a sufficient scenario?
Heather: The virtual session I am talking about where there is a white board with multiple items that have to occur. A deaf person or blind person to come in and what is their experince?
Shawn: Look to see where the existing scenarios can be enhanced. Perhaps add a couple of aspects to that.
Heather: Self paced learning and the live virtual classroom, both are literally putting the classroom online. You have a particpant, with a power point back up, and talking into VOIP, or a bridge, and lots of different factors. Not so Black and white. The current scenario is self paced. Doesn't have a chat room, or sending files into it.
Shadi: Shall we add something along those lines? Kind of self paced. Add some comments specifically about how it could be improved? What additional information to provide for a reader. Someone new to accessibility. To get an idea about what to do. Not a primary goal of the document to list all possible is important, accessible tourism is not indicated. The use cases would transpose to those different domains.
Heather: I think live learning is important to do.
Shawn: Heather or Wayne to suggest what to add.
Heather: To have a self paced scenario is important. It is rapidly growing.
Shadi: To make sure the comment is not repeated, but add some perpsective about live learning.
Heather: I have researched extensively. I'd like to fill in the gaps.
Shawn: Another place it might work better could be in the training resource suite. We talked about the need for accessible training. Heather you might have some good information for that.
Heather: I think there needs to be a good scenario here.
Wayne: what about a blind person
who attends an online meeting?
... we should not just be looking at the students.
Heather: They are all adult learners. A meeting could be a phone conversation and nothing exchanged. Live learning has to involve learning exchange and IT that has to have accessibility built into it.
Shadi: I hear that from Wayne, real time and accessible is important.
Doyle: How much is augmented information included in the scenarios?
Shadi: Let's finish the first point. Build in real time information?
<Shadi> ACTION: Shadi to consider adding aspects of "real-time" and "multi-channel" communication (possibly in scenario #3 as as virtual training or in scenario #4 as virtual meeting) [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action10]
<Shawn> ACTION - Heather & Wayne - suggest changes to scenarios #3 and #5 - maybe also accountant with blindness add teleconference. look at adding real-time and multi-channel. remember overall purpose for this document, and that some points are covered in the other scenarios.
Wayne: I could do a training scenario. But we also hold meetings that require all the features of online professional training environment and IT mediated.
Shawn: We have actions on that?
Heather: For the EO list?
Shawn: Most useful is the specific suggestions to existing scenario.
Heather: I'll do that. I'll consult with Wayne also.
Shadi: There was a question about augmented information. Not sure where to put that in.
Doyle: My main concern is for mobile devices.
<Shadi> ACTION: Shadi to consider adding use of GPS for orientation (buzz word "augmented reality") in scenario #8 [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action11]
Shadi: The eighth scenario is how to use the cellphone. I put in GPs as a good example.
Wayne: I have new topic for this. Dyslexia is where you would address reading. That actually the biggest use of the web is just plain reading. We have to mention that online libraries are helpful. Some are not avaialable to her assistive technlogy. She has to go to a resource center to use.
Shadi: The idea is that not all web sites are usable for her. To mention that she must to go to the library to get information converted to a different format?
Wayne: Yes, most learning institutions have a resource center, and she needs to go to the center for disability resource to get inaccessible materials converted.
Shadi: Is that the case in all countries? This is going into a bit too much detail, perhaps? We have to be careful how much we pack in.
Wayne: But we have not covered reading adequately or effectively. When they are lost and part of course and they need to use a resource center. Can't go through in one course without running into one site that none of these work for.
Shadi: You are talking about format or reading?
<Shadi> ACTION: Shadi to consider file format issues in scenario #5 [recorded in http://www.w3.org/2010/03/05-eo-minutes.html#action12]
Wayne: For several reasons this is of a very high level of importance. In a
file format not served by accessibility support for their
devices, they run into a barrier. There are several scenarios
that aren't addressed.
... they are going to have to find a conversion resource.
... not just file format issues. 20 percent of the time a
student has to work on this.
Shadi: I will address these comments and have taken note of them. I'll work on getting these in there if possible. Comments?
Wayne: I think this will be international. Help for finding a resource for converting text.
Shadi: Any other comments on this page? I'll try to work in the comments, but otherwise that page is pretty stable?
Liam: Really good Shadi!
<Liam> Looking really good!
Shadi: That's good. This is the first page, so it be good to tie down, for the benefit of the coming pages. We'll take a look at cross linking once the other documents are completed.
Shawn: It sounds like we'll have a few things to change still. Additional comments please send those by email.
Shawn: we talked about Vienna,
W3C technical plenary will be Lyon France, first week of
November 2010. For those of you haven't been to T-Pac. On
wednesday presentations, and throughout the week, many of the
working groups have face to face meetings. Cross group work,
T-Pac is a really good time to do that. EO typically does meet.
That means though if we did both of those we would have two
meetings in one year.
... can people attend both? Or just one because of over all
travel. I'm guessing we would like to have both, partly because
we get so much done. November is a good time to meet. comments
now? On one or both of those?
Wayne: I'll probably go in November. I'm not ready for traveling in July.
Shawn: Liam?
Liam: yes I would like to go to
one and possibly both!
... they are both nearby.
Shadi: Come to Vienna.
Reminder: Update attendance surveys and see current topics for work via email
Shawn: Please up date those attendance surveys. Please keep updated. Very useful for our planning. A reminder if you we have some documents you can comment in email, better web browsing, get those now, rather than later. We can integrate those with the same edit tasks.
<Shadi> http://www.w3.org/WAI/demos/bad/draft/2009/
Shawn: I sent an email about reviewing the Before and After Demo. We would like to publish as a draft, the 15th or 17th of March before CSUN. We need any comments and an OK from EO next week. Any suggestions or comments about BAD demo?
<Andrew> request for BAD comments
Shawn: Question any objections pending the opportunity to review, generally objections to publishing the BAD demo as a draft? In the middle of March.
<Andrew> No objections
<LiamM> No objections
<IanPouncey> No objections
Doyle: No objections
<Wayne> No objections, do it ASAP
Shawn: OK anything else?
Andrew: Australia is adopting WCAG 2. I'll let people know.
Wayne: Do you have any idea what the new 508 is doing with respect to WCAG 2?
Shawn: Initially no.
Andrew: That should be announced any day now.
Shawn: Have a great weekend and complete the surveys. Talk to you next week.