Involving Users in Web Accessibility [working title]

Shawn: The first link goes to the requirements and analysis.

<Shawn> http://www.w3.org/WAI/EO/changelogs/cl-impl-users.html

Shawn: First item is the requirement for involving users in Web Accessibility.
... let's skip the title brainstorms. Two main things here. A reminder of what this is. We wrote a document a few years ago as part of an evaluation resources suite. This document more explicitly talks about users in the design process and includes older users. A big issue with this is scoping. How can we make this a useful resource and draw a line of not making it too big and complicated?
... Another important point, really make the primary audience the web site designers or coders and project managers, but not usability specialists. We want, after we finish this document, to do something for usability specialists.

Andrew: Those are the key things to keep in mind.

Shawn: Comments? Scope and audience especially.

<achuter> No comments

<Zakim> Shawn, you wanted to remember to ask someone to clean up minutes afterwards and to remind them of the time change next week

Shadi: I was actually advocatingfor dedicating this to standards web developers and now it may be too much about them. Involves them too much by inviting them to the table and making them addressed.

Andrew: A different type of developer to involve as end users.

Shadi: A different type of involvement at some stages. From the beginning by putting up requirements and making sure you include end users in 'use cases'. This should be involving all of these groups.

Shawn: Lets' take HTML 5 and include them in your use case. Including real people?

Shadi: Either real or representations. When we take many developments we try to actively involve users in the standards process.

Helle: I would like to support Shadi on this. A lot of activities in Europe a lot of users are involved. Important to raise the idea when people work on standards it's important to have users in the standards work itself. How to take into account all the people with special needs - see eg JTC1 doc on @@@.

Shawn: If we add something to this document for a users audience. A small section or paragraph, something for this audience - how much it would overlap here?

Shadi: If I look at the intro it opens up quite nicely. Starts with a nice broad definition, and drop web services and then throughout the document say web developers and specifically mention them throughout. Do a basic text that includes all sorts. Like browser manufacturers.

Shawn: Any other comments?
... Let's look at the draft document itself now. Also let's come back after looking at the title.

<hbj> The JTC1 SWG-A reports are ISO/IEC TR 29138 Parts 1-3

Shawn: Over all reactions? Particularly especially the length. We've done little editing to take out - mostly added. Too long, is it good, should it be longer to cover more details?

alan: I want a little more a detail, but otherwise seems to have everything there. Overall comments on the overall contents.

Jennifer: Ideal to not get much longer.

Shawn: Already pushing it for length. One section we can cut down.
... Alan specifics?

Alan: In the introduction, you could say it is not just a web accessibility to ask people what you make of it as you design. Something like that?

Shawn: The first sentence needs to say that more clearly?

Alan: In web design this is often overlooked or something like that.

Shadi: I think everything is there. I really like the examples and skimming wise that's really helpful.

Andrew: Somewhere in the introduction, we already have the business case for web accessibility and this document supplements and if we could cross reference to the business case somewhere?

Shawn: Where it says involving others with accessibility needs or link at return on investment. Or maybe increasing usability to include people with disabilities there. I don't think it is worth two sentences, but a short way to do it maybe?
... fits more with the usability document, not as much here.

Andrew: you accept the business case for accessibility, and use that here rather than just the guidelines.

Jennifer: I'm not sure where it might fit for the business case - possibly link the BusCase to this.

Shawn: What else?

Jennifer: I think this was the document. For myself I found the examples are important to make this concrete. I thought there were too many blind references though.

Shawn: Yes, and Andrew brought up the one example of screen readers. Maybe we could come up with others.

Jennifers: Does this include tables?

Shawn: Yes. Think about some strong examples with PWD with other disabilities. Particularly older users.

Shadi: Keyboarding?
... For all the users the first thing that comes to mind is text enlargments, but keyboarding comes to mind like skip links. Keyboard users are massively disadvantaged.

Shawn: A kluge on the developers job because the browsers don't do that. Another example?

Andrew: Contrast comes up fairly often too.

Shawn: How does that fit here on this document?

Andrew: Having this tested for, as (older) users have diffrent vision from developers?

Shawn: We need examples like a developer to follow the guidelines who doesn't understand how PWD use the web and they did the wrong thing and didn't understand what they need, and the second analyzing disability issues. One the developer didn't mark up right, and number two the assitive technology doesn't work right, and three the user doesn't know how to use the assitive technology.

Shadi: The developer who doesn't know how to do the right thing should be there. Not dealing with the users and the usability, claim to meet the actual requirements and didn't spend time to meet quality.

Andrew: go to all the effort to make a complex table they should spend time to do a simple usabilityy instead of complex code markup.

Helle: what you said Andrew is also a content problem. Who decides what goes on the web site. Something about navigation within the site. Very often people skip the headers. If you don't have to go through the document. I can't come up with an example other than to benefit the blind user.

Jennifer: I think the problem is we often so often relate to screen readers we are at the same blind centered examples. Harder than it ought to be in my opinion.

Andrew: It is hard to appreciate keyboard-only users when you can tap tap as opposed to when you can't tap tap.

Shadi: It has been shown that it is quite different when you can see and the focus goes all over the place. It is a different kind of keyboard use from the screen-reader user.

Jennifer: how can we use that idea. That could be a good one. That people might not know.

Shadi: I need more time to think about that. A whole list of skip links that was an over kill of skip links. The issue they all didn't appear. You didn't know what was going on visually. I don't know if that is good example to use though.

Shawn: what else?

Jennifer: that is the main issue (blind-centric egs) that jumped out at me. I might think of other things over the weekend.

Shawn: Please do send comments in the next couple of days. I'll take another pass at it before the face to face. I'd like to get comments before so we can speak about in the f2f.

Improving Your Web Experience by Using Adaptive Strategies [working title]

Shawn: The previous document is called including users in web accessibility evaluation. Involving users in web development. And I thought about involving users in web development that's more formal and good, or including users for better and easier web accessibility

Sharron: I think better easier is a better title.

Andrew: The title shows up first in most searches.

Shadi: I don't want to stick to web development. I like better easier because it is more motivating. But I don't know if it means all users.

Shawn: if you have ideas for other titles send to t;he list. Now back to the second items.

<Shadi> [Involving User for Effective Accessibility]

<Shadi> http://www.w3.org/WAI/EO/changelogs/cl-adapt-strat.html

Shawn: Shadi? introduce this?

Shadi: This is primarily about users who benefit from accessibility built into the OS and browsers and don't know how to configure them. Or who are scared of playing around with the system. And people who could benefit from the tools. All the way to assistive technologies and specialized technology. But don't come to the idea these exist.
... many people do not get the right things. Could be used in a lot of IT training. While the primary audience speaks to those users. But our primary audience would be trainers and supporters. Secondary audience doesn't speak to them.

Shawn: An indirect primary audience. Indicate that?

Shadi: OK.

<Shadi> ACTION: Indicate that trainers/educators are indirect primary audience [recorded in http://www.w3.org/2009/10/23-eo-minutes.html#action01]

Shawn: What specific things to focus on for this requirements page?

Shadi: Explain adaptive strategies without using the terms. To not scare off because they don't relate to disabilities. Mention either approach though. Comments?

Shawn: Here is something that jumped out at me. You said something like they might not be aware of what they can do, or might be scared to. I think that is a huge issue with a lot of people. I know people who are not computer literate they are totally unwilling to try anything. They might blow it up.

<Shadi> ACTION: Indicate that motivating people who are afraid of reconfiguring their systems is probably a huge issue and difficult to address [recorded in http://www.w3.org/2009/10/23-eo-minutes.html#action02]

Andrew: or acquired computers skills acquiring a disability.

Shawn: I have worked with a few new computer users who tend to be anxious about errors for even up to a few years.

Shadi: Let's jump over to the actual document. The document is a very early outline now. The place holders, looking for a catchier title, and not have adaptive in there. Should be in simple terms and motivating. Retain that style throughout the document. In the subsection about figuring various bits about ...and various hardware. Not a step by step guide. We may link to several resources out there that may help users.

Shawn: What would that section look like? Here is what you can do and that is the directions for how.

<Andrew> outline draft

Shadi: For most browsers you can control text size, and then link to some resources for how. High lighting those that exist, and maybe colors. To provide additional info about what kind of tricks there are. An eye opener for most people. For most platforms that can be mentioned. Suggest looking under the options tab but not really more than that.

<Shadi> ACTION: Think in terms of functional requirements of users [recorded in http://www.w3.org/2009/10/23-eo-minutes.html#action03]

Jack: One way to approach. Begin with a link or matrix kind of thing. Something functional of what you want to do. And then mention style sheets to go from what they want to accomplish the disability they are trying to deal with. Related that to a particular function like their web browser or media player.

Shadi: Not sure it would turn out as a matrix. That would be a good approach.

Jack: Put it in as a matrix, that's how you want it to appear. But the really important thing is to relate to a function and user requirement.

Shawn: That's a really good idea because it could help users determine where to start. LIke what do you want to do, see better, hear better that kind of approach.

Shadi: Do a sub heading to turn this around a bit.

Shawn: Do a new heading to see how this works. Maybe a possibility to do both. If I was in as step by step mode I would want existing option. But this is not a step by step instructions.

Shadi: The over all construction would involve the media player and browser. Use that instead of user.
... Start off by saying improving your web experience, instead of optimizing, and ...

Shawn: Making it easier to use web sites?

Shadi: Making web sites easier to use.

<Andrew> [get more from the web/browser/@@]

Jennifer: I vote yes for that one.

Shadi: But that makes it sound like what developers should be doing.

Helle: Isn't it something about customizing your web browser?

Shadi: More than just customizing but something like customizing.

<Shawn> How you can make websites easier to use

<Andrew> Make your web experience better

Helle: Have something about how you can do individually. Saying how make web sites easier to use. Better for your own specific needs or preferences.

Shawn: I like the word customizing?

Helle: Yes.

Shawn: I think web experiences is very jargony.

<Andrew> Get more from the web

<Shawn> Customizing how Websites Work for You

<Shawn> Make Websites Work better for You

Helle: Make the website work for you.

<Andrew> Better website interaction

<Shadi> [interaction]

Jack: So far the suggestions are focusing on the individual. What you are really talking about is adapting your software instead of the individual.

Shawn: I am thinking of the target audience. Say I am a trainer at a class for computer users at the senior housing center. What would they be looking for? This would be useful.

Andrew: Good point. Once we have some that we think are useful. Then ask some trainers what would appeal to their audience.

Shadi: I am trying to think of the end users. A sub title might help here?

Helle: They talk about how to set up your computer or browser. They have a much more general way to talk about and sounds to us unspecific. They know what they are talking about.

Jennifer: Make the web work for you.

<Shawn> Setting up the computer...

Shawn: The target won't be setting up the web, but the set up of the computer. Good to shift the outline from configuring the web browser, etc. Something in the title the idea of keeping open the idea of a sub title as well to meet both perspectives.

<Andrew> Setting up your computer / makng the web work better for you

Shadi: Keep in mind while we speak to users and trainers, we want to show browser venders, there are so much more benefits for the users. Speak more in the web sphere. More targeted to the end users we are talking to, but having a title more web centric.

Shawn: Comments on this document, approaches for the next round?
... both of these documents are on the agenda for f2f. We have a list of readings to talk about. As soon as each one is stable we'll give you an update. People going to the f2f are here on the call. We want to give you in plenty of time to discuss. For some of these the f2f is the last significant discussion. How early do you need the doc stabilized. Get me to day or next Friday. Weekend or as soon as possible during the week.

Doyle: I'm easy.

Jennifer: I am a weekend person.

Sharron: I'm pretty open. Weekend is fine.

Shawn: If you have early in the week?

Jack: Get to me by next Friday.

Helle: I would need before Friday. I use the weekend for traveling. I would have to look at Thursday or Friday. Preferably Thursday. A big family thing on Saturday.

Shawn: We'll get some stuff stabilized by the beginning of the week. Any questions or comments of what we will be doing with these documents.

Slides, discuss any issues sent to the mailing list

Shawn: The first one is the benefits of access slides and the quotes are now in the slides. If you have a comment about placement let me know. And also about the visual design. Comments are welcome are welcome also. I did quickly in powerpoint but we want to carry through the HTML version. Somebody who is decent with CSS. A colleague or something to be up for doing the CSS.

Sharron: I'll look into that. By the end of today.

Shawn: Won't be too hard. Comments on the slides?

New Accessibility - W3C page - more images?

<Andrew> accessibility page

<Andrew> email comment

Shawn: The last thing on the agenda. A comment in the email in reply to that, saying there is too much text on the pages, and should be images. I replied that shopping sites are much easier than more abstract material. A lot easier to convey with a picture. Thoughts on that idea?
... for those around for the WAI site redesign. How hard to have one image that adequately represent of what we want to represent. What about having a series of images? How the web is designed to work with all people, a list of differences. Overlaps with mobile and older users. A series of small pictures different people using the web and different situations, some having obvious disabilities. Would strengthen the page?

Jack: Tell us more?

Shawn: Near the introduction. Had seven pictures and one was someone using a head stick to type. Somebody using a mobile phone. Someone who is blind. Someone in a location in a remote village. Each picture, the human in each picture has a different ethnic background

Jack: How people use the web, pictures that go with the different case scenarios. Provides the diversity you want.

Shawn: Show an older user,maybe have a kid also.

Shadi: We will continue to have our differences on this. If saying that is the shoe you are buying we won't show the lamp. Show tham as clearly related. I don't want to try a hand bag, not a shoe. Clearly show this is about PWD and older users. That is a requirement of what we develop for.
... I don't want to hide the disability aspect.

Shawn: The intro starts out this is for everybody which includes disabilities. I would say of the seven pictures, four should have obvious disabilities. The other three should show the mobile and additional benefits. Part of the whole picture. What we were trying to convey in the first page.

Shadi: It's not about the web as a whole but about the four PWD. Mobile web standards what do we get. Let's see what if this work.

Shawn: I wanted to address this only if we feel strongly to take this on.

Andrew: The email as I recall as using illustrations is reducing the amount of text one has to read. This may not reduce the text significantly.

Jennifer: One thing I would say about reducing the amount of work. If that was used, the pictures should be used elsewhere also. In general I agree with the idea of more pictures and videos. People are trying to wrap their heads around the concepts so text heavy pages can be overwhelming. Get a big bang for the investment of space.

Jack: Part of what you want to do, is not use a single image for different situations, but get several that are robust enough that you can use in several situations.

Shadi: For those scenarios. To have images to attach to or something.

<Shawn> [ personas for wai site redesign http://www.w3.org/WAI/redesign/personas.html ]

<Andrew> ACTION: Andrew to consider including pictures with the scenarions in "how pwd sue the web" - add to changelog [recorded in http://www.w3.org/2009/10/23-eo-minutes.html#action04]

Shawn: I agree. We wanted to put more pictures on the site, but we didn't get it done. As reminder for the personas we had pictures.

Shadi: Maybe the images are larger with PWD and the other more in the background. As part of the point as a site as a whole this site is about PWD.

Jennifer: There are a lot of disabilities that you can't see in a picture. Differentiating between with and without disability plays into stereotype.

Sharron: That's right, there are many cases of invisable disability.

Jennifer: The assitive technology conveys the theme, but with many people you can't tell.
... that is why I liked your idea Shawn. All blended together.

<Andrew> Maybe a montage

Shawn: Possible in five or six pictures.
... walk through the agenda for f2f.

Jennifer: I don't think we need to walk.

<Andrew> f2f agenda

Shawn: We will need scribes. Particular topic you would like to scribe for. Think about what point you would like to be a scribe. Let me know. You will get the time slot for the document you want.

<Zakim> Shawn, you wanted to remind time change next week and to remember to ask someone to clean up minutes afterwards

Doyle: yes

Shawn: Next week we meet, Shadi will be chairing the meeting. We need someone to clean up the minutes.

Sharron: I will clean up the minutes.

william: I will be the opening keynote for the W4A dinner in NC next year.

Shawn: Good.

<Andrew> s/double A/W4A conference

Shawn: Everybody have a wonderful weekend. Have safe travel.

<Andrew> s/Topic:/Topic:/

<Andrew> s/Topics:/Topic:/