The EOWG convened this week to discuss the feedback received from the group concerning the option to publish the WCAG-EM report tool. Three questions were asked of the group with the following outcomes:
The meeting adjourned with a reminder to update availability for teleconferences and F2F and to check the wiki for next week's work.
Shadi: We have to make some decisions about what to incude. We agree that we need to get something published soon, but want to be sure it has quality to make people say "oh this is a great tool." even it they also say "I just wish it had such and such a feature." So we are relying on you to be sure we have a good first version.
<yatil> https://www.w3.org/2002/09/wbs/35532/21JanWCAGEM-TaskSort/results -> Survey results
Shadi: we will review the questionairre which is not all of the comments (remember we addressed many more on the wiki). Is it clear what we are doing?
Wayne: We are not discussing the shuffle sort thing today?
Shadi: We will if we have time after we discuss the WCAG-EM Tool
<shadi> https://www.w3.org/2002/09/wbs/35532/21JanWCAGEM-TaskSort/results#xq1
Shadi: The first consideration was one that would require us to change the library itself. Technically it meets WCAG and had no issues with the current browsers we used. I am wondering if anyone in EO has had any issues with font sizes?
Wayne: I'd like to take tomorrow and look more closely but I have had no problems on modern browsers. People who rely on large pring tend to update their browsers, so I would not expect it to be an issue.
Jon: What older versions are being referenced?
Shadi: Opera on Windows
... And that is a question we need to ask ourselves. As WAI we tend to try to do quite a bit of backward compatibility and so we need to decide what is possible and practical. I am also waiting to hear from Shawn.
Jon: I can do another round of tests if needed.
Shadi: Thanks Jon and unless Jon brings new information, I think we proceed with the current code library. If Jon brings more info, we may need to do some kind of a hack.
Shadi: It was an old version of Opera...
p class='phone'>Wayne: Opera handles user style sheets and we may be able to develop one specific to that.Shadi:...on an old version of Windows.
Wayne: may not be able to help, I retired my last XP machine last year
Shadi: So at this point are there any objections to proceeding as proposed?
All: None
<shadi> http://www.w3.org/WAI/eval/report-tool/
Shadi: The menu bar at the top has functionality that is not always relevant but which does not change in relation to the relelvance. For example, "save report" does not make much sense on the entry page (before anything has been entered) and "open report" does not make much sense beyond the entry page.
<yatil> https://www.w3.org/2002/09/wbs/35532/21JanWCAGEM-TaskSort/results#xq2 -> Results for question #2. Menu bar at the top
Shadi: when you are in the middle of the pages, "Save" will be the most important. So the buttons have different relevance at different stages. We played around with ideas like a floating the menu bar and chaging the order of the menu buttons or having them appear and disappear depending on the page you are on, but each approach has drawbacks.
... so we are proposing to leave it as is, leave the menu buttons as they are now and allow people to use them as they will. It did not make sense to put "Save" as the first button even though it is the most important and most often used. Instead we will introduce a shortcut key to do that at any time.
Sharron: Releasing it as is will allow us to get actual user data and not have to guess how people use it.
Brent: I noticed that in the instructions, there is a reference to the buttons. It is important that those buttons are there when the instructions are being read.
... Another question was use of Open in the middle, but it could happen.That should be explained
<shadi> ### error message when trying to open report over existing data ###
Shadi: I am making a note of giving an error message when trying to open report over existing data.
... another suggestion was to float the menu bar so it always stays within the screen even when you scroll down and need to Save or something. It may be useful, but it is quite deep and takes up a lot of screen area and especially with screen magnification. We have not found the solution but are considering a few. In the meantime have added Back to Top and are considering a keyboard shortcut for Save.
Sharron: Not to float the menu bar seems like a good choice to me. Is the keyboard shortcut implemented in this version?
Shadi: Yes it will be. The floating menu bar is soemthing we may have in a future version.
Wayne: Floating menus are a bane for large print users and I generally don't use those pages because it is too hard.
Shadi: There may be a way to do it on the side or something clever that we have not yet thought of. But the question is should we try to address people's need to Save often or access the menu bar for this version or just publish as is and keep thinking of the solution for a next version?
Sharron: It sounds like the best idea to include the shortcut key for save and back to top and just table the fixed header for later consideration.
Kevin: Rather than fix the entire header you may just consider fixing the Save icon
Shadi: How important is it to have for the first version?
<shadi> ### add ctrl+s as a tip on the save dialog ###
Kevin: May not be critical, but in addition to giving the key commands in the instructions, include it as well on the Save Report page
Brent: I like that idea and another thing you might consider providing a tip that shows when the button is used.
<kevin> +1 to Brent
<shadi> ### add ctrl+s to the button itelf ###
Shadi: I am hearing a few improvements - the shortcut key and prompts - for this version and the idea to table the floating menu until next version
... any other ideas or counter proposals?
All: None
Shadi: The next problem is related to Steps 2 and 3. In practice there tends to be considerable back-and-forth between these two steps (exploring the website and selecting sample pages from it). In 2 you are taking notes as you explore and discover new technologies used in various places. In 3 your notes are preserved and then the tool supplies the "common" pages and allows you to add according to your notes. You select pages and as you add them it also increases the number of random pages that must be included.
...because of the back and forth between these steps, and the possibility of encountering new technologies while in Step 3 that would send you back to 2. Some found it confusing and suggesting to merge Step 2 and 3.
... Merging steps 2 and 3 would require quite some reworking, and would lead to a fairly complex combined page. We would prefer to keep it as it is in Version 1.0 and gather experience on how this tool is used in practice, to think about future
... but some think it is such a significant change and if that change is made later, it could alienate people who have been using it. Your thoughts?
Jon: I see the point that it could be a usability issue. My opinion is more aligned with Brent's. Constantly going back to the previous step is quite distracting. I don't see it as that significant however. I think encouraging people to explore the entire site is the best course and wait to see how it is used in the real world. If we get complaints, we can address at that time.
Shadi: I like that perspective and it may be that the back and forth may be more than we suppose. What if we find that the back and forth is a problem and we need to change later on. Will that change be off-putting to people who have been using the tool already?
Jon: You know there is a really good video on YouTube about changing tools that people are accustomed to. Suggest how to make the change gradually so people did not have the strong reaction. If it is a drastic change it could happen. But if we make it gradual, not so much.
Wayne: I agree with Jon. As well I think another dimension is consideration of the size of the organization. I think we should consider the merging but we must consider that in a large distributed organization the steps will likely have to remain separated.
Kevin: I wanted to add in that if this becomes identified as a significant problem users, the change will be welcomed even if they are used to it.
Sharron: +1 to Kevin
Shadi: But should we consider that if it is a great problem people will not use it in the first place.
Kevin: There is a strong argument to connect the two together, not to get rid of the step but to connect it in the tool .
Sharron: I don't think the back and forth is enough of a problem to keep people from using it. On the contrary, I think many will be happy to have a tool like this
... Once it is being used, then we can get more data about how real people use it
<metzessive> +1 to people digging the tool
<kevin> +1 to Sharron
<metzessive> You have no idea what it means not having to check against a checklist.
Brent: The design of the tool and specifically steps 2 and 3 causes confusion. As I use step 2, this is my page to explore, then when I get to step 3 I get the same functionality. I see the list of what I previously chose and then see that I can continue to choose more pages. I think it may be better if you see just a list of what you have chosen and instead of having to reenter, you should be able to slelct as random sample. The design combines the functionality on step 2 on both pages. was that the intent?
<Wayne> Are Steps 2 and 3 really one multi-part step?
Shadi: These are good points. We have the common web pages and at the bottom of page 2 the selected pages. The other aspects are actually note taking, information that will help you make the slelection later on.
... Maybe it would be useful to move the step 2 choices to step 3. So by then you would actually insert the short names and URLs at that time. So separating functionality more clearly.
Shadi:Thanks everyone for your input. Watch the wiki for next week's work and we'll see you then.