[Draft] Analysis for [WCAG 2 Quick Reference]
Shawn: The Quick Reference be collapsible. People said this was too much as is. Too complex. The motivation for the timing of this revision.
<shawn> http://www.w3.org/WAI/EO/changelogs/cl-wcag2-checklist.html
Shawn: what we want to do the
goals are for the re-design, input from users, different types.
Starting from analysis document.
... A little background, and fill in with compelling
information about notes and audience. Open issues and concepts,
and starting use cases. Comments?
Liam: I'm not sure I understand?
Shawn: we talked about in a WAI meeting. Currently there is how to link to Flash reference. Separate links to go out of this page to understand the link bits. Do we still want to do this. Stay on the page and expands and collapses. One page? page for developers, different roles for ways to use WCAG. Idea might you choose your role, policy person, web site developer. Expand or collapse around the roles. Comments?
Liam: I'm not sure there should be a division between evaluator and developer. If you don't understand it you can't evaluate.
Shawn: this is preliminary.
Sharron: role of policy maker is questionable. I'm not sure the policy maker would use this in much details. A whole other pathway and options for policy makers could be a waste of time.
Liam: I have a concern about the shear number of expansion levels, expanding and expanding.
Shawn: I thought this also. Maybe the understanding in there and have the techniques later.
Liam: understanding the checklist as one.
Shawn: we tried that or started to try. More complex than thought. One technique can be related to multiple success criteria.
Liam: a bread crumb problem. Check back to that.
Shawn: Other thoughts? Important things about the background, purpose audience?
Liam: how do you envision this working for ATAG or UAAG?
Shawn: they are talking about doing an understanding document.
Liam: This would work for ATAG and UAAG?
Shawn: the design would.
... Let's look at the use cases.
... we don't want to have too many, but have enough that cover
a good range of target uses.
Liam: check complex site. Could be quite a complicated use case.
Shawn: to make it work for that?
Liam: yes, although you could make it an export for use cases.
Shawn: realistically does one might want to use this? We might do for them?
Sharron: what about trainers? Train other people to design accessibly? Would they use this or not?
Shawn: differently from someone else?
Liam: we don't use differently.
Shawn: see use notes that notes Trainers to use these.
William: a pre-canned use case for developers?
Shawn: that's one possibility
shadi: deals with WCAG 2 in the use cases. Use as a reference.
Shawn: how is that different from number 4
Shadi: I don't know. Maybe about WCAG 2 to use?
Liam: I agree with Shadi. Condensed for someone to use. More concise than someone coming to it for the first time.
Shadi: something to go directly to without all the explanation.
Liam: without a precise guideline.
Shawn: say more about policy and procurement would use this?
<Liam> could have verbose (for learners) and concise (power user) versions
Shadi: I am thinking when you are developing a policy for a University. With the impact you might not want to go to so much detail. For procurement similarly about cost something you can copy and paste. Something to help you decide what you might require. Take out a lot of the techniques out of the way. To get an overview of the impact of the policy.
Shawn: Sharron?
... the rest of these use cases, I know and am comfotible with.
Policy and procurement I trust you Shadi. Some know policy and
procurement go to this detail.
Shadi: I'm not set in stone about this. When the interface is just for technical people or include policy makers or procurement, they have a high level view or audience. Try to learn more about their needs or not. I'm not married to this.
Shawn: Ok.
Shadi: were there concerns about this?
Sharron: before you got here they would look at this for this much detail. They know there is a standard and meet it, but give this over to their technical people. When you talk to them, use this but don't understand.
Shadi: maybe this interface could help them. Maybe the fragmentation is caused by them not understanding this. They might re-invent the wheel. So an expansion that says what double A is. Does this help?
Shawn: in the background, one of the things we talked about, playing with the terms, WCAG in the street, something simple. A couple of years ago I pushed for that because it was so jargony. Now is a lot less jargony, but you drill down to learn the details there are so many details. So we might integrate some explanations. The guidelines and success criteria with two sentences of simple expalnation.
Shadi: annotation to help explain the technical comments could help with three and two. Very rudimentary sites moms and pops stores. They would be helped by the view with WCAG 2 at a glance. Intergrated as a resource for this space. Could drill deeper for the technical folks.
Shawn: There is a web page now WCAG at a glance. Hope to print as little cards. The front of this would be similar to WCAG at a glance.
Shadi: the start interface or default view of at a glance would be the start?
Shawn: we could consider that. The length of it. The principles and check paraphrased.
Shadi: I mean if the WCAG 2 at a glance could be considered a resource as an input. Might be a useful view. For people who are non technical.
William: a prerequisite in the how to meet document. Not mentioned there. First look at this maybe you don't need to be here.
Shawn: The wording is not that
different, main we did was to shorten it to fit on a card.
Ok.
... Anything else with what we are trying to do with this? Do
you see you would like to use WCAG 2?
... did anybody to proof of concept and play with the notes?
That goes down and thrown together really quick to figure what
information on one page.
<shawn> http://www.w3.org/WAI/EO/Drafts/quick-ref/beta1-1
Shawn: Proof of Concept (POC)
link. goes to a URL page whose title is still "how to meet WCAG
2.0)
... if you want to play with expanding this. Rough pass draft,
you can click on the time based media.
William: two very different pages have the same title.
Shawn: I threw something together. There is a link that is active, Time based media is live. Click on that and expands to more information. Another one is Success criteria for WCAG 2, that expands to quite a bit more information.
Shawn: we are playing with that to find out how much is too much. Looking at expanding and collapsing to have something to play with. Trying to see if it was feasible to put the understanding and techniques on one page.
Sylvie: I see on each H2 twice the same information. The screen reader repeats it twice and I have too much information.
Shawn: Using Fire Fox?
Sylvie: no, with IE. Note from Sylvie: after tests with firefox the results are the same. It seems to be due to the use of text and images in the hN sections.
Shawn: maybe a browser issue. Could be because they have titles on them? Any first reactions seeing something like this again? a POC not set in stone. comments?
William: have to do a usability analysis of this. The ones you put in all of them have that much detail is a little daunting.
Shawn: Ok
william: that is good.
shawn: we have a little more for the analysis. We have something to hang discussion on. I'd like to go around to people on the phone conference, what's working and not.
Liam: I'm not keen. I'm trying to work with why I'm not keen. You don't get a sense of what's in there without opening everything up. When you explore you find it overwhelming. When do you stop expanding?
Shawn: going back to the current version. Is the difference because it includes the understanding info?
Liam: it's just the expectation management thing.
Sharron: I think that this is one of those things, you find out the idea of expanding to reveal more finite information than this. When you have this much information the bread crumb idea Liam had before. You realize you go somewhere you will get a lot more information. When you expand here you are scrolling all over the place. Most useful when the information is more compact.
Shadi: I had a similar reaction. I wonder if we can use some of the Web 2.0 widgets and technologies here.. I don't want to expand the scope but this might really improve the handling of a large amount of information.
Liam: a collapsible interface instead of expanding. You start with a good understanding of what's there.
<shawn> http://www.w3.org/WAI/WCAG20/quickref/
William: if you have an 'expand all' it would come to a hundred pages.
shawn: let's look at the quick ref. Starting with this. With those who use this, the default settings on this? What do you use.
Liam: I show smile techniques unclicked.
Shadi: I don't have settings on this page. Quite difficult to navigate and scroll.
Sharron: I have smile techniques unclicked. Level one A unclicked.
Yeliz: Level one unclicked. complicated on the expand page.
Shawn: What works well for you. In
terms of the user interface for you what works?
... What works with this. How could this be made to work better
for you?
Liam: I do refer to this quite a bit. I do need to refer on stuff on still. I would navigate around this with using my find command on my browser. Like scripting control f and look for every reference to script in the document.
Shawn: you have by default every technique shown?
Liam: yes.
Shadi: I would like a small option to collapse.
Liam: they are at the top of the document. I don't want to get rid of all techniques. Just those I don't want.
Shadi: switch off the techniques and have a switch on, I don't want all expanded. Have some expanded together. Open sometimes. Open the techniques and not the failures and sometimes the other way around.
Jennifer: A report template was built so you could get from there?
Shawn: question is to answer those. At your check off level, you do at the success criteria level Liam?
Liam: yes.
William: I'm objecting to the see all this other stuff. Techniques.
Shawn: you can get it if you could go to the techniques, but not clear from this that is available. The way I like to use sounds a lot Shadi's. Having any of the techniques is too much. Just have the success criteria. I might say to myself what does this say and expand the techniques under that.
sharron: I think it is good we are thinking about but I don't have anything else.
sylvie: I have to look closer to the drafts to have something to say.
Shawn: Look at current How to Meet: Quick Ref and the analysis page. don't focus too much on the "proof-of-concept" - it was just a playing with one idea. Don't get too tied to that. What we currently have broadly.
Jennifer: quickly, back to Shadi was mentioning earlier. I keep envisioning a tree structure. Expand and collapse that way. I haven't seen an ARIA do that. I find that more potentially manageable. Hard to envision with having a mock up.
Shadi: I like the idea about checking off things you have done. We are going into a sort of evaluation interface. An interesting idea to play around. A bit of scope creep. Especially for complex what you have done and come back to see what you have done.
Shawn: There is an analysis page a check off what I have done. I'll put a note done level versus techniques.
Sylvie: in response to Shadi's comments we had a conference in June about WCAG 2, and we request our evaluators with reading only WCAG 2 and supporting documents, read guideline one. Check if one point one is met or not. They read the success criteria, the how to meet and the techniques. We gave them 20 minutes, to review 3 success criteria on the page. But they had only time to read the documents and not to review the page. It would be helpful to *sort* everything. If I have frames on the page, which success criteria do I have to review, which techniques, which failures? Same questions for images, forms and so on.
William: if I tried to use this thing, I can't turn off HTML techniques. If I turn off techniques and failures it doesn't change.
Shawn: we are aware of that, you have to click below. Techniques and failures. Far down the page you can't tell, so none of us can tell. A thing I want to look at whether it was worth to turn on and off those technologies. Turn off 5 out of a hundred things. Turns off such a small percentage that you can't tell. Very useful comment.
Shawn: reminder of what we are
doing here. We have an existing business case here. We want to
add an appendix here. We have case studies, like return on
investment. We have one page that has this kind of
information. We have a list of case studies. We look at what
that case study looks like. We found that if like with legal
and general we couldn't find a single source with the
information that is essentially useful.
... Liam and others pulled things that would meet the
conditions we want.
Liam: The first one is a nice celebratory one. The next two, this is what happens you don't do it right. Worried about titling a little test we thought we would a celebratory case instead of a court case.
Shawn: questions about why we are
doing this?
... look first at the legal and general one.
Sharron: this will be a useful place to send people. I love the way it is organized. Really good. The resource page.
William: I wonder to have some paraphrasing external data, that we could collet similar parts that are response. Useful to have redacted real responses?
Shawn: in reporting accessible
sites? Send in as an idea. Send to Andrew and WAI dash
editors.
... let's look at the legal and general. Can you remind us Liam
of what we had suggestions for changes from the last
discussion?
Liam: we have shifted the opening quote from the parting quote. Apart from that there are not many changes to the legal and general. We had a discussion about quoting from blog articles referencing that are PR puff pieces. Or heard reported some place and hard to come back to the original source of information.
Shawn: what works? Any
suggestions?
... when you look at the main page, there is right now, two
data points or something. Have we talked about having summary
at the top that would be those main data. What was listed in
the main page, and case study itself. The key data points at
the top.
Liam: yes no haven't been done, but a good idea. On the general one, the resources pages. We could put a tag line on the H1.
Shawn: yes, and change what you have there after more research.
Liam: quotes be kept then? Repeating the two data points?
Shawn: what feels stronger stats at top as the summary instead of or in addition to the quotes.
Sharron: I think the quote is stronger. Not a thing floating there. Quotes does not go to the bottom.
Jack: I agree with Sharron. Powerful at the top.
Shawn: do you think should be on the resources page? Or a summary of that?
Sharron: A kind of summary of the quote now. At the top of the general case page.
Liam: slightly different in that ...
sharron: align the two.
Liam: absolutely.
Shawn: the numbers get lost to me in that quote. Appropriate to bold a couple of things?
<yeliz> I agree with that as well
Liam: I don't think you should embolden things is the quote.
Sharron: synopsize or emphasis the numbers on the resource page by shortening on expanding. Say these things and not in the case study.
Shawn: not a strong disconnect. I want some numbers. I see quotes and I don't care. I finally get to the results which is what I really want. I want the numbers at the top, and then what is the change. Really cool The thing I want them to see. That sucks them and now that I see this is significant. Someone might get lost before you get them exicted.
William: put in a ellipses, cut maintenance costs by two thirds period.
Liam: when you introduce ellipses to a quote it feels less strong.
Shawn: leave the quote but see another way to print out the numbers. we assuming they might start at the resources page. They might not.
Liam: The reason we put so much information about the business, was because we wanted people to feel that this was upfront. They feel in the right place, before explaining first before the numbers. My concern is with you put the results up front. You seem to be just repeating.
<yeliz> +1
Shawn: that's fine this is just one perspective. Other comments? Do you approve publishing on the WAI site?
Sharron: yes
<yeliz> +1
William: yes.
shawn: any objections?
Jennifer: Liam have you shown this page to legal representatives. Have they signed off to?
Liam: All public information. Has come up to look at headline data. Legal have shouted about how important it was.
Shawn: I would agree it is not necessary. Nice to get on record Liam we did this and that should come from W3C.
Liam: acronym tag around LMG.
Sharron: Last time we talked about this, we got all the AIR participants to sign off to make public. A lawsuit got thrown out of court and they made some substantial changes. To get some pride in making these improvements. Afraid to be sued on the right argument.
Shawn: Liam used tiny URIs instead of linking?
Liam: very long to have the name but could link to the main from the URI?
Shawn: I would prefer.
<yeliz> I agree with Shawn
Jennifer: I was thinking that too. Might have quick throughs. With these short things might die.
<yeliz> you can also judge the quality of the reference
<yeliz> if it is linked directly
Shawn: using bit leavers instead of linking directly. I am in favor to link directly.
William: I would if a survey document by some lawyer to explain what is suggested by these examples?
Shawn: wouldn't be something WAI
would publish. Not something more current state of legal
status. Anything else?
... the next one is TARGET
Liam: we are describing the progress of the court case and the structure is different in describing the case study.
Shawn: over all comments?
William: no description of what Target has done as a results of this?
Shawn: the point we are trying to say if you make accessibility improvements we say what improvements you have, and if you don't the consequences.
William: I understand what that means but what did they change?
Jenniffer: maybe we know what they were required changes.
Sharron: we know they have to be audited twice, and what they changes.
Jennifer: could they review this? Looked like all about money to me.
Sharron: they had to make improvements and still make improvements.
Liam: I'll email Jim, but I want to be very careful to quote not editorializing. We'll need to see if it is clear in the settlement.
William: Jim's blog talks about it.
Sharron: It talks about in general ways. Did he say specific improvements?
Shawn: we don't ask for information that is not out there anyway.
Jack: on going changes that need to be made and monitored compliance
Sharron: exactly monitored compliance.
Shawn: the agreement was to make their site accessible.
Jack: monitored compliance scares most corporations because of the on-gong court ordered monitoring.
shawn: what does this point out?
William: this is an outcome of doing this stuff. Makes it desirable stuff, to do this rather than have a settlement.
Shawn: you end up doing the work anyway, and you paid money also. The attorney's fees were made semi public, makes the 6 million look like chump change.
Liam: who?
Shawn: I know where to contact and how to find on line, or who has the document that states that.
Liam: I am making notes in my comments. X million.
Shawn: by that way was what there
was. Part of the agreement to pay NFB legal fees.
... one could estimate that X for NFB then 2X for Target.
<Sharron> terms of settlement http://www.dralegal.org/cases/private_business/nfb_v_target.php
Shawn: include the actual settlement in the resources. Stepping up a level does this communicate this clearly.
William: absolutely. Comes across very clear.
Shawn: Target corporation settles with NFB. Makes sites accessible to the blind. Come across both points at both places.
Jennifer: Did they pay six million. Up to amount.
William: trust fund.
Liam: they had to pay out.
Sharron: they had six million in a trust fund. And a lot of other expenses.
Shawn: way more than six million. I'm looking about and the resources page.
Liam: basically change the tag lines to reflect the case study.
Shawn: do we want to add each?
Liam: not to get repetitive.
Shawn: we want to be accessible to everyone. There are two points to get across one cost the company a lot and you end up making the site accessible. Make this point at both places or too much?
Liam: I don't see why it couldn't be done.
Shawn: Anything else? Right amount of detail? The right length?
Sharron: accessibility consultants aren't paid enough.
laughter
Shawn: the right amount of detail
yes no, anything else on this. Liam has a few tweaks to make.
In the first sentence under about the business.
... Important useful?
William: yes gives you the idea of the scope. Governmental in scope. I would comment on this I've had waited this a long time.
Sharron: really good work Liam.
Shawn: Target originated in 1902, but I don't care about the name.
Liam: we wanted to give a sense that this is a big corporation. Identical to what they write on their own site. Apart from this court case I've never heard about it.
Shawn: anything else? The next one is the Syndney Olympics web site.
Jennifer: felt like switching the case on the time lines.
Liam: yes a single case. I'm away as of Saturday for two weeks. Make sure you send through says about Accessibility in the subject line.
Sharron: Phil Jenkins was quite involved in this. As well as Jim Thatcher.
Liam: IBM was doing this?
William: yes.
Liam: I guess one thing about IBM
does this matter to the case study?
... feedback on which of two versions. Very briefly with an
overview focusing on the results, and this one more on the
arguments. Kind of arguments about a large company would make
to not do, but doesn't cut it.
William: the technology detail, none of that shows up in the target one. People ask me what were they doing wrong. How to fix? In an hour?
Liam: we can't fix now argument. We do on-going improvements. They lost the case because of that.
Shawn: Anything else?
Liam: happy with HOROC as an acronym?
Shawn: I think it easier than the
alternative.
... Liam you will be gone for two weeks. Make changes so we can
point to them in the meantime?
... anything else for today? Have a wonderful weekend?