W3C

Site Navigation

Nearby

Results of Questionnaire EOWG Weekly Survey – 25 May 2015

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: shawn@w3.org, ee@w3.org

This questionnaire was open from 2015-05-22 to 2015-06-04.

9 answers have been received.

Jump to results for question:

  1. Quick Start Tips: Previous Review
  2. Quick Start Tips: Titles
  3. Quick Start Tips: Your Input on Content
  4. Quickref feedback
  5. Quickref: Tags
  6. Quickref: Search
  7. Quickref: Any other feedback

1. Quick Start Tips: Previous Review

The in-progress draft Quick Start Tips is now in Github. They include previous EOWG input from the wiki and the weekly survey on the tips for each.

Please indicate your review of the tips text.

Summary

ChoiceAll responders
Results
I reviewed all the Tips in the wiki previously and put all my comments in the wiki or the survey. 4
I skimmed the Tips in the wiki previously and put some comments in the wiki or the survey, but I need to review them more thoroughly. 4
I didn't get to it previously, and will review them soon. 1
Not so interested in this resource, I'll pass.

Details

Responder Quick Start Tips: Previous Review
Andrew Arch I reviewed all the Tips in the wiki previously and put all my comments in the wiki or the survey. also added some thoughts via github
Eric Eggert I reviewed all the Tips in the wiki previously and put all my comments in the wiki or the survey.
Sharron Rush I skimmed the Tips in the wiki previously and put some comments in the wiki or the survey, but I need to review them more thoroughly. I know we are not meant to comment on design yet, but we may as well start thinking about alternatives to the frame. Also should there be an way to get from one subsection to another within each page?
Brent Bakken I reviewed all the Tips in the wiki previously and put all my comments in the wiki or the survey.
Howard Kramer I didn't get to it previously, and will review them soon. I've reviewed the Tips. It looks clear and easy to follow. As I and others mentioned on the call, I think icons next to the roles would help. Only roles I found confusing were distinguishing between developer and designer. I think this was mentioned on the last call. The different sections/headings of the tips for each role need to be more distinct. They don't stand out as well as they do on "Easy Checks" - perhaps because there isn't extensive content at this point.
Vicki Menezes Miller I skimmed the Tips in the wiki previously and put some comments in the wiki or the survey, but I need to review them more thoroughly.
Shawn Lawton Henry I skimmed the Tips in the wiki previously and put some comments in the wiki or the survey, but I need to review them more thoroughly.
Paul Schantz I reviewed all the Tips in the wiki previously and put all my comments in the wiki or the survey.
Melody Ma I skimmed the Tips in the wiki previously and put some comments in the wiki or the survey, but I need to review them more thoroughly.

2. Quick Start Tips: Titles

The tips pages are listed on the draft overview page as gerunds (Designing, Developing, etc. ending in "ing"). The draft pages have placeholder/straw titles of "Accessibility Tips for [Design]".

What thoughts do you have for how we might want to title the sub-pages?

Details

Responder Quick Start Tips: Titles
Andrew Arch Current approach seems ok as long as we inlcude all aspects of [design] and/or have good sub-titles
Eric Eggert I like the “Accessibility Tips for [Design]” wording. I wonder if it makes sense to use Accessibility Tips more as a breadcrumb, for example:

<small><a>Accessibility Tips</a></small>
Design

(But that is editor’s discretion and just a suggestion.)
Sharron Rush Suggested:
"Inclusive Design Tips"
"Inclusive Development Tips"
"Inclusive Authoring Tips"
"Accessibility Evaluation Tips"
"Tips for Accessibility Integration"
"Tips for Effective Advocacy"
Brent Bakken One idea...
A continuation from the descriptive language on the overview page. "These guides provide you with practical tips to get started with web accessibility,..."

- Designing for Web Accessibility
- Developing for Web Accessibility
- Authoring for Web Accessibility
- Evaluating Web Accessibility
- Project Managing for Web Accessibility
- Advocating for Web Accessibility
Howard Kramer I like the way the sub-pages are currently titled - e.g. "Accessibility Tips for Authoring Content"
Vicki Menezes Miller I would prefer to have a continuation of the links. I see no issue in the titles containing the same wording as in the overview links, i.e., click on the link and go to a page with the same wording:

Designing: Tips for visual design and interface design.
Developing: Tips for front-end coding.
Authoring: Tips for writing content for the web.
Evaluating: Tips for website evaluation process.
Project managing: Tips for planning and managing web accessibility.
Advocating: Tips for championing accessibility in organisations.

Alternatively,

Designing tips for Web Accessibility
Developing tips for Web Accessibiity
Authoring tips for Writing Accessible Content
Tips for Evaluating Web Accessibility
Managing projects to include Web Accessibility
Championing Web Accessibility in Organizations
Shawn Lawton Henry I think there needs to be clear front-loaded relationship between the links on the overview page and the title of the individual tips page.

Especially for users who land on a Tips page without going to the overview page first, I think "Quick Start Tips" needs to be clear in the heading. Also, probably good to provide redundant nav to the overview page.

So maybe the pages are titled:
Quick Start Tips {which is linked to overview page}<br/>
Designing for Web Accessibility

Then the overview page lists them as Brent suggested.
Paul Schantz Pretty sure I've seen these titles elsewhere, but just as a suggestion: "Designing for Accessibility," "Developing for Accessibility," etc.
Melody Ma Subpages should have the same title as the navigation.

3. Quick Start Tips: Your Input on Content

Later we will consider the design of the Quick Start Tips, including whether they should be integrated in the WAI website "wrapper" or not. For now we're focusing on the content. Kevin will be fleshing out the tips (putting the explanation and learn more links) this week.

Please contribute your input on the text of the tips or the explanations via Github or otherwise. Thanks!

Details

Responder Quick Start Tips: Your Input on Content
Andrew Arch suggestion: "Accessibility Tips for Authoring Content" > "Accessibility Tips for Writing and Editing Content"
Other suggestions via github
Eric Eggert (guess I won’t get to that, sorry.)
Sharron Rush have reviewed and note are made, will submit via GitHub (if I can remember how to do that)
Brent Bakken I really like how simple the content/text is. I think the less wordy all of this is, the more it will get used.

Comments...
Design: "Present text in a good font size and line length". Need to use a different word besides "good", something more definitive or informational.

Development: "Check your code validates" - Should it be "Check that your code validates"?

Authoring: "Make the text in links clear", change to "Math the link text clear". "Provide alternative text for all images", add "and non-text content" to the end of the statement.

Evaluating: "Run early and early quick reviews", not sure what this means, needs a better phrase. "Run evaluation sessions with real people", change to "Conduct evaluation sessions with real people". Additional tip, Include final accessibility statement/documentation on site or product papers.

Project Management: Additional tips, Work accessibility into the planning phase of the project/development cycle. Develop and implement an accessibility responsibility matrix. Incorporate accessibility lessons learned into future development and projects.

Advocacy: Additional Tips, Identify and promote accessibility training, resources, and tools. Give recognition to accessibility champions within the organization. Seek talent and employ people with disabilities.
Howard Kramer The current text on the quick start tips are clear, concise and well written.
Vicki Menezes Miller I like the easy to understand approach.
Shawn Lawton Henry
Paul Schantz
Melody Ma

4. Quickref feedback

At AccessU we collected user feedback for “How to Meet WCAG 2.0” (quickref).

Please look at the feedback we got and consider the questions below.

Summary

ChoiceAll responders
Results
I reviewed it 5
I skimmed it 1
I didn't get to it 2

Details

Responder Quickref feedback
Andrew Arch I didn't get to it
Eric Eggert I reviewed it
Sharron Rush I reviewed it
Brent Bakken I reviewed it
Howard Kramer I reviewed it
Vicki Menezes Miller I didn't get to it
Shawn Lawton Henry
Paul Schantz I reviewed it
Melody Ma I skimmed it

5. Quickref: Tags

One of the major findings was the request to be able to filter through WCAG more easily and also to be more specific than we are right now.

The page layout needs to change to make room for tags and to make people aware how they are used.

Clicking on a tag would surface the relevant Success Criteria as well as techniques, and links to tutorials. Other Success Criteria would fade out and put on the bottom of the page.

Please look at this unstyled, non-functioning mockup of the possible future direction of this resource.

What are your thoughts on this change?

Details

Responder Quickref: Tags
Andrew Arch
Eric Eggert (editor)
Sharron Rush It seems to be a good direction to meet many of the needs expressed by those who provided feedback. I am a little bit concerned that we do not have a broad enough sample to change direction, but defer to those who have more user testing experience.
Brent Bakken I like this idea. Just a bit concerned about the amount of tags that we may end up with and how much that pushes the filters down the page to where they are not noticed and therefor not used. Interested in seeing what comes out of this design direction.
Howard Kramer As I mentioned on the last call, I like the outline view on the left. I think the tags concept is a good one but would not like to see the left navigation/orientation outline go away. Perhaps having the tags on top or right is an alternative.
Vicki Menezes Miller It seems like a good approach as long as the number of tags doesn't get out of hand.
Shawn Lawton Henry
Paul Schantz It's a lot cleaner looking and easier to read.
Melody Ma Tags are tough to navigate. Unsure if it's practical for navigational purposes.

6. Quickref: Search

User feedback indicated that people didn’t know how to use the search, some even misinterpreted it as a search for the complete WAI website. The usefulness of the search has also been questioned (as it performs similar to in-browser search.

There have been different solutions proposed to solve this. Which do you suggest and why?

Summary

ChoiceAll responders
Results
Remove search at all.
Keep search, but make it more clear that it belongs to the page content. 4
Keep search, but use it only to search through the tags, so people might be able to find a tag they want to get to more quickly. (This assumes that we have a lot of tags.) 2
Keep search as is.
None of the above.

Details

Responder Quickref: SearchRationale
Andrew Arch
Eric Eggert (editor)
Sharron Rush Keep search, but use it only to search through the tags, so people might be able to find a tag they want to get to more quickly. (This assumes that we have a lot of tags.) Don't have a clear enough idea of the consequences to make definitive judgement now but I tend to think if we make the leap to tags, those would logically be the main search criteria
Brent Bakken Keep search, but make it more clear that it belongs to the page content. Each user has their own preference of how they go about finding things in a document, web site, or tool such as this. I think the search functionality should remain but be better defined so that it is always an option for those that find it useful to their methodology.
Howard Kramer Keep search, but make it more clear that it belongs to the page content. My understanding - and based on my own use of systems - is that search is always important. People will turn to search when they can't find information in other ways. And then there are some people who primarily look for information on any resource via search.
Vicki Menezes Miller Keep search, but make it more clear that it belongs to the page content. I think it's important to keep search. People tend to resort to search when they are unable to find something or when they want to find something quickly.
Shawn Lawton Henry
Paul Schantz Keep search, but use it only to search through the tags, so people might be able to find a tag they want to get to more quickly. (This assumes that we have a lot of tags.) I echo Sharron's thoughts
Melody Ma Keep search, but make it more clear that it belongs to the page content. Search is important. When developing, that's all I use for finding keywords the proper sections as a cue into which section is applicable. Tags would not be helpful because I wouldn't know where to start.

7. Quickref: Any other feedback

After reading the feedback so far, do you have any other comments on the feedback? Have you identified any other things that you think we should prioritize?

Details

Responder Quickref: Any other feedback
Andrew Arch
Eric Eggert (editor)
Sharron Rush Do we feel we understand how people use the QuickRef now? Are we confident that the redesign will keep existing users engaged with it while simplifying the output to attract others?
Brent Bakken Would it be useful to add a couple of example case studies to help people understand how to use the tool. For example, if someone needs to understand more about the correct way to provide information around links, labels, roles and naming forms, tell them the step by step directions of what to click on (appropriate tags, filters, techniques) to end up with the exact SC and info they are looking for.

Walk them through how it works with a real example of how someone would search for something and find the correct info.
Howard Kramer
Vicki Menezes Miller
Shawn Lawton Henry
Paul Schantz As I was scanning the comments about filters and search and keeping this resource up-to-date, a weird thought occurred to me. Has anyone within W3C considered building an API for sharing WCAG 2.0 Guidelines and SC? It's well-organized information and lends itself to reuse in this way. If W3C had such a resource, the content could be repurposed in any number of useful ways.

Maybe this is just a crazy idea...I dunno. What do you all think?
Melody Ma Visual design is getting very cluttered. Need to rethink before launch.

More details on responses

  • Andrew Arch: last responded on 27, May 2015 at 11:59 (UTC)
  • Eric Eggert: last responded on 27, May 2015 at 12:34 (UTC)
  • Sharron Rush: last responded on 27, May 2015 at 17:50 (UTC)
  • Brent Bakken: last responded on 27, May 2015 at 21:27 (UTC)
  • Howard Kramer: last responded on 28, May 2015 at 07:47 (UTC)
  • Vicki Menezes Miller: last responded on 28, May 2015 at 19:44 (UTC)
  • Shawn Lawton Henry: last responded on 29, May 2015 at 02:57 (UTC)
  • Paul Schantz: last responded on 29, May 2015 at 04:00 (UTC)
  • Melody Ma: last responded on 29, May 2015 at 06:18 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Eric Velleman
  2. Shadi Abou-Zahra
  3. Sylvie Duchateau
  4. Kazuhito Kidachi
  5. Jedi Lin
  6. David Sloan
  7. Mary Jo Mueller
  8. Reinaldo Ferraz
  9. Bill Kasdorf
  10. Cristina Mussinelli
  11. Kevin White
  12. Kevin Rydberg
  13. Adina Halter
  14. Denis Boudreau
  15. Laura Keen
  16. Sarah Pulis
  17. Bill Tyler
  18. Gregorio Pellegrino
  19. Ruoxi Ran
  20. Jennifer Chadwick
  21. Sean Kelly
  22. Muhammad Saleem
  23. Sarah Lewthwaite
  24. Daniel Montalvo
  25. Mark Palmer
  26. Jade Matos Carew
  27. Sonsoles López Pernas
  28. Greta Krafsig
  29. Jason McKee
  30. Jayne Schurick
  31. Billie Johnston
  32. Michele Williams
  33. Shikha Nikhil Dwivedi
  34. Brian Elton
  35. Julianna Rowsell
  36. Tabitha Mahoney
  37. Fred Edora
  38. Rabab Gomaa
  39. Marcelo Paiva
  40. Eloisa Guerrero
  41. Leonard Beasley
  42. Frankie Wolf
  43. Supriya Makude
  44. Aleksandar Cindrikj
  45. Angela Young

Send an email to all the non-responders.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.