The training resource suite update comments have been documented in the wiki and a large number have been taken into consideration. Those which are for future consideration have been added under such heading. Except for some minor items, this is now really close to release, if possible, for end November.
The Preliminary Evaluation is coming along. Wayne had the opportunity to actually to use it on a job and this was proved to be very useful in terms of judging the time alloted and the level of evaluation. The goal is to get as many checks in there and then to start looking at how to filter them. There are some concerns on how to address testing and tools. The four items which were open for drafting have been filled and should be ready for next week.
Evaluation in process will be ready for next week. The group are invited to add their comments as the document develops. Likewise, Ian and Vicki are invited to bring any questions they have to the group for discussion next week.
A discussion took place on the audience for WCAG EM and, in particular, where do developers fit in, how are accessibility professionals defined. A comment from the Group should go back to the Eval Task Force.
Agenda item no. 3
Andrew: Quite a lot of comments. Thanks. On the whole, good feedback. At the link on the agenda, all comments that were provided are there apart from last. The comments are documented in the wiki and I've sent some comments back to Shawn.
Shadi: I see one comment for discussion and one pending. Let's pick up the open ones.
Andrew: Suggestion to add a tip for speakers to attract advanced web developers. I've taken that on board and am looking where to link it to. One idea was in the IndieUI WG page. Should we add that link at this point or wait until there is some draft material in the IndieUI page?
Shadi: I think that there is an Indie UI page.
Andrew:I was looking for something in the Indie UI wg page. I think that the Indie UI page is the obvious page to link to and I think that works well. As you say, it would be the place for web developers to pick up some of that work. Is everyone happy to add that tip for speakers and link to the Indie UI work?
Suzette: I would add some reservations
Andrew: I think the Indie UI page is going to continue to develop and it's a an enticing topic for buddng web developers, more than just content and it does link nicely to the mobile topic. I will change the current link and use the Indie UI page. The other suggestion I have left for discussion on this page is the conformance for evaluation topic. We should think about the link which will probably change as the page changes to reflect the WCAG EM work. I thought we should probably start linking to that. It depends on the timing on when it's released
Shadi: Easy change. Just as long as it's on someone's radar.
Andrew:The other comment not incorporated (from Shadi) was adding some additional topics into the workshop outline page, adding topics on mobile, accessible web design and expanding the checking topic. Would require some revision., also building those topics. We should think of it in future rather than holding up the publication at this stage
Shadi: Add to the link for future consideration. Any thoughts about this?
Shadi: Thanks for the great work. Really glad to see this work coming to closure. I've seen the action item for me to add the expand/collapse script and will try to do it as quickly as possible.
Andrew: It would be nice but if you haven't got it ready before publishing, we can go without it.
Shadi: I'll do my best since it would be so nice to publish it with it. I think Shawn is trying to publish this within the coming week or by end of November so please make sure to take a look. I think that there are now just polishing up touches, no dramatic changes.
Andrew: Mostly editorial improvements.
Wayne: They make a difference though
Shadi: Let's go to the next topic No. 2 http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation
Wayne: I used this on an actual audit last week and it was really good. It was great for testing. As regards the tools, I don't quite know what to do. You can test WAI-ARIA with open source available plugins. Kind of thinking that the 17 points is a little too much. I was able to check 7 pages in a day using this list. That's a pretty tedious test. If you do want to prove yourself for the next level, it's pretty much where you stand. We need tools of static representation, color contrast, luminosity contrast. We may need to think about how we need to deal with tools.
Shadi: That's an important point. Also, the time factor for checking. On the other hand, it's more thorough than the quick check. This will continually be coming up. What to include, what not to include. Focus really that this is a quick check. This might also relate to your question on ARIA. Even if you know that a certain widget has landmarks, it's not really an indication that it works. Testing WAI-ARIA in 15 minutes is a challenge.
Wayne: I'll try and write something but it's difficult without a tool.
Shadi: I wouldn't know how to test ARIA without a tool.
Wayne: I'll just go ahead and put a test with a tool. I'll do the color, too. I've also noticed some results of the color tools. Also, checking link text was really tedious.
Shadi: It would be good to know which tests take longer and see what we can package into the 15 minute check. From your real experience, this would be really useful to know in terms of time.
Wayne:There was one piece of terminology which seems odd. I don't think it's stated well. I'll look for it later.
Shadi: Suzette, I there is one assigned to you.
Suzette: There is only that one. I was doing a comparison of the different ways of describing the audience, eval. methodology, overview, different scenarios. This is where I put my time. I'll try and do it today.
Shadi: There are some that are open for drafting. Shawn asks if someone wants to take them up.
Wayne: Let me do the WAI-ARIA and if I have time I'll come back to the color.
Shadi: We have color coding, content order, tables, text flickering, flashing, blinking. Four are open. Ok, folks, who's up for the challenge.
Vicki: I'll do content order
Suzette: I'll take color coding
Andrew: Does color coding include shape?
Shadi: Do you want to add a note for consideration if it's a different check or if it's the same. Probably, another check.
Suzette: We tried to make sure that the different checks are linkable to a success criteria. I'd look first at the success criter to see how it's scoped out.
Shadi: It's one criteria which is independent of color, shape etc.
Wayne: Should we change it to visual coding or single mode coding?
Suzette: I think for the preliminary document, my personal preference is user-friendly title, if we go down the road of the technical accuracy, then, we may tend to make it more like another standard.
<shadi> 1.3.3 Sensory Characteristics
<shadi> 1.4.1 Use of Color
Shadi: Looking back at the full standard, the one Andrew is talking about is 1.3.3 and the one on color coding is 1.4.1 called use of color. They are both level A. They are cross linked because they are related. Andrew, could you add a new text for that?
Wayne: Let's keep one for both.
Shadi: Another approach is to develop them separately and then see if we can combine them in one step. Right now, we're just in the phase of collecting tests.
Wayne: Good idea. Put in more than we need now and then consolidate.
Shadi: I think they're both going to need to be manual checks anyway.
Andrew: Makes sense to combine them in the test.
Suzette: Shall I do the color coding and the shape coding?
Shadi: Yes, try and see if you can combine them in one check or do they need to be separate?
Suzette: Ok. I'll see how they fit.
Ian: I can do tables for the week after
Shadi: Can you put your name and time required
<Sylvie> I could find some time to help. What has to be done that nobody is editing?
Shadi: Flickering, flash and blinking could be done in the same way for the color code etc. Basically, it's a manual check.
<shadi> Sylvie: 1.3.14 Check flickering, flashing, blinking [open for drafting]
Shadi: So, Sylvie, flickering.
Shadi: Looks like we have it most done and with the exception of the tables, we should have them done for next week, so we can go to the next step, combining, filtering out etc. Everyone please review what's there and read the discussion questions in the agenda for next week. This will be the main agenda item for next week so make sure that you are up to speed with that for next week.
Shadi: Next agenda item No. http://www.w3.org/WAI/EO/wiki/Eval_in_process
Thanks, Ian, for adding the information.
Ian: Vicki and I are going to add to the wiki and come back to group for discussion for next week.
Shadi: Shawn does say for both of you, questions and thoughts will rise and you may want to discuss with the group, if you have some questions, just shoot an e-mail to the list. Try to get the group involved as you are still working on it. Everyone please review what's there and the read the discussion questions in the agenda for next week.
Suzette: We set up a little analysis of scenarios of developers and various types of people to think about. I've done a comparison between the three variants we have and in doing that, I've come up with a question, in the overview document, I was wondering, what exactly do the developers have in relation to the EM document.
Shadi: Good question. It depends on how you define the developer. Primarily, WCAG EM is usually aimed at usage after the content author has done their work. It's a post development check. WCAG EM may not speak as well to the developer as the success criteria
Suzette: Maybe you can read what I've written and we can discuss. My concern is the developer's role in relation to WCAG EM.
Shadi: I'm looking at the discussion tab. Comment on use cases. Is that the right part?
Suzette: No. 2 target audience comparison.
Shadi: Has anyone else seen this?
Suzette: It's new since this morning.
Shadi: Maybe people need to read this and revert.
Andrew: I tend to agree with this discussion. Developers are probably a secondary audience.
Suzette: I was curious after comparing the three documents. It seemed in the other two documents, there wasn't a strong position for the developers. Just wondering if we were on the right track.
Shadi: There may be need for references in the WCAG EM and Overview to say that Evaluation in the Process is the right resource, as such, we are redirecting them to the right place, i.e., where the developer is really evaluating their own work as they develop.
Suzette: Well, the developer might put his Evaluation Hat on but you're probably right they might want to be in the evaluation process during development
Shadi: Correct, that's what we want to be very clear about, i.e., evaluating throughout.
<Andrew> point developers to http://www.w3.org/WAI/EO/wiki/Eval_in_process#Development_Stage type material
Suzette: Probably, you shouldn't also run an evaluation on your own site
Shadi: Yes and No. Developer needs to check their own stuff. In larger organizations focused more on development, they would have specific testers in such a testing role, or at least open bug reports. Only a the very end would be WCAG EM.
Wayne: We need to look at evaluation in process and preliminary review. That whole long list of things we have would help evaluation in process.
Andrew: Agree absolutely. Preliminary evaluation can be used as a progressive check. Especially more complex techniques we mightn't use in true prelim eval
Wayne: Also, it is organizationally dependent. If you have an organizational process, that's one kind of preliminary review. When you look at a wireframe, you're already doing a preliminary review.
Shadi: Accessibility professionals - you want to say more about this, Suzette.
Suzette: I think it's in the draft overview at the moment. Knowledgeable people comes over quite strongly. In the overview document, there's a very strong message for someone who has hands-on experience and knowledge about accessibility evaluation.
Shadi: Looking at the contractor which is the closest to the developer, then, there's a content writer...
<Wayne> There are a few types of accessibility experts. Immediately I can think of technical experts (may be auditors, but could be developers), legal experts and teachers.
Suzette: I just wanted to get it out into discussion. The purpose was to decide what's going into the overview document, but then I realized it impacts the original.
<Suzette2> the draft overview wiki is at http://www.w3.org/WAI/EO/Drafts/eval/wcag-em
Wayne: A lot of people who do accessibility audits are accessibility experts in their own right. Then, there's teachers, legal experts, too. Just some thoughts about how we express that.
Shadi: I now understand what you're trying to say. We do have some comments from EO in that direction and that could be an additional comment to resend to the group. It's a bit over the deadline but good to have the discussion in EO and try and get that finalized with EVAL Taskforce group as an additional comment from EO. Things are moving. The developer as such should be specifically spelled out and redirected to the resource. At least, we should flag this. Look back at the comments and see if there was something along this line. So, maybe you can refine the comment once EO agrees to the change.
Wayne: That point just slid past me.
Shadi:I think it slid past everyone. Thanks a lot for this. That's the final point of our agenda. Any comments, questions?
Thanks everyone and a reminder about the reminders. Till next week. Shawn will be back.
Shadi: Please remember to regularly update your availability. You now have an extra hour to do so.
Another reminder is action items which are posted on the Working Group page.