Planning and managing web accessibility - design

http://w3c.github.io/wai-dynamic-planning/

Kevin: Last week's take away was to bring ideas together for putting activities all on one page. I've put some options - not yet polished - together. Let's look at these three options (open to alternative idea) and determine if any of these work for us.

<kevin> http://w3c.github.io/wai-dynamic-planning/initiate/

Kevin: First one is on the initiate section. Have mocked up two columns with activity on the left, description with option to expand or collapse. The share icon does not quite work as intended (still to be fixed).

<kevin> http://w3c.github.io/wai-dynamic-planning/implement/

Kevin: Second idea is in the Implement section: tried to stick with styling and structure (similar to WAI web site), expand/collapse attached.

<kevin> http://w3c.github.io/wai-dynamic-planning/plan/

Shawn: if we went with *no* expand-collapse, after each section, we could have a "back to page contents" links

Kevin: The third idea for completeness - possibly the simplest - each activity exposed all on one page. There is no short introduction blurb. Just has the core of the activity on the page. So, these are the 3 ideas.

David: I find the simplest could be the most appealing (the last). I don't believe the content has the level of complexity that merits the navigation.
... so I prefer the one that has no collapse and expand.

Annabelle: I was going to say the same thing. I really prefer No. 3. It's simple, easy to scan and to understand. There isn't a huge amount of stuff in each section. The other 2 look more cluttered to me.

Andrew: I have a slight option for expand/collapse option on the "Implement" one.
... Because you can skim and get an overview. I felt I had the big picture more quickly.
... The first one was hard to skim. I didn't like the initiate option. The second was easier to scroll.

Vicki: I prefer Implement - can scroll and get the big picture. The last one (Plan) is too wordy at first impression.

<yatil> Tally: initiate: 0 / implement: 3 / plan: 2

Howard: I guess I also like the implement one because I can get a better sense of the overall process. See all the different sections. Found that helpful. The dotted lines also helped with separating the sections.

Shadi: Do you feel "On this page helps"?

Howard: I think it helps to have it there. I could go either way.

<Andrew> thinks 'on this page' helps a bit too

Howard: The reason I may like it is that you know immediately how much content is on this page even if you don't look at the specific topics. My preferences are kind of mild.

Eric: I don't feel very strongly but most of the time the simple option is the best. I like the planning one with everything on one page. If it works for Tips, it works here as well.

<Andrew> Tally: initiate: 0 / implement: 3 / plan: 3

Shawn: I find on the second one, on Implement, Read more about, is redundant and cluttering. I think if we could set it up so that we didn't have to have that extra line. On the Initiate page, you have expand/collapse without the extra line,.
... My preference is Implement with a little tweaking or the first one with a little tweaking.

Brent: I didn't like Initiate for the same reason that I think that Andrew commented it was hard to skim. The titles would sometimes wrap. So, my least favorite was Initiate. Torn between Implement and Plan. I like Implement a little better because you can quickly skim down the page. But I think it's a matter of getting used to whether is everything shown or not shown. I like Implement because you have Expand All if you want to see everything.

<Andrew> Tally: initiate: 0.5 / implement: 4.5 / plan: 3

Brent: Anyone else have any other opinions?

Annabelle: I heard a lot of people saying that there preference is mild. I am quite strong on my preference.

<Andrew> Tally: initiate: 0.5 / implement: 4.5 / plan: 4

Shadi: Could you explain a bit more?

Annabelle: I think the most important is what works best for the user. I feel very strongly about No. 3.

<Andrew> +1 to end user is more important than our 'expert' views :)

Shadi: Is the Expand All section not as apparent? From Implement, you can get to something which looks like the Planning one, but not the other way around.

David: I feel pretty strong about this as well. We want to do everything to make the content available. Although I can think of many examples where expand/collapse are very useful. But for these pages, I feel the pages are simple enough and that the expand/collapse may be little hurdles. I do want to say I like the inline links at the top. I really like the plain language used.

Shawn: Two points: I wanted to channel James thoughts. James was strongly for having the expand/collapse and he hasn't seen these options. The expand/collapse allows users to have the information how they want to browse it. If a user wants, they can click expand all and the only complexity is a plus sign next to each heading. But there are users who want to skim and get the overview first and see one chunk of information at the time. If we do provide expand/collapse, we meet a range of user needs.

Eric: My feeling is that another navigation option brings another cognitive load to the system. I probably don't see the Expand All. I think it makes it rather complicated. I don't feel really strong but I do think that this is a cognitive load for users.

<davidberman> +1

Shadi: Just to highlight what Vicki has said, because the Plan page has too much text, it comes across as daunting/heavy and we have this comment on many of our resources. I just wanted to put this out also as an argument for people to think about, how much is this deterring to people as well. Howard also liked to skim through the headings.

Vicki: +1 Shadi

<AnnaBelle> I don't think any of these are "long" blocks of text

Howard: I think I used the word unconsciously. I think long blocks of text can be a little overwhelming. The main point I wanted to make is that this is also a process. One sentence what this is about helps to bring the point across to quickly absorb it.

David: I think that there is a balance here. If we could afford usability testing, we would need to deal with how to deal with the content. Perhaps, we should number the content on the page and it might help navigate - by giving some sort of order to the steps - it gives a sense of process of where you are on the page.

<shawn> -1 to numbering -- we talked about this a while ago and decided we did not want to suggest that they have to do it in order

Brent: Any other comments about these three options

David: Yes, I recall. We had discussed this.

Sharron: What would it be like to have Implement without the list at the top? I was one of the people against the idea of numbering - it is not consistent with the use of the resource. This is not a strictly sequential process.

Brent: I just want to take a final vote to see where everyone is. So, we have 3 options: No. Initiate (expand/collapse across double columns), No. 2 Implement (expand/collapse), No. 3 Plan (no expand/collapse). Could everyone put in their preference please?

<AnnaBelle> strongly prefer #3

<davidberman> I prefer #3

<Sharron> preference for 2 implement with no linked list at the top

Vicki: No. 2

<Howard> preference for implement

<Brent> #2

<Andrew> mildly #2

<shawn> prefer 2 with tweaks

<yatil> strongly-ish prefer #3

<davidberman> I will not block concensus on this item.

Brent: 6 votes for No. 2 and 3 votes for 3 are very strong. I know we need to come for consensus. Shawn, some advice on how we could reach consensus?

<Andrew> not everyone is present tonight either - can we vote during the week?

<AnnaBelle> I asked can we do A/B testing programatically? The answer seems to be no.

<shawn> Kevin can set up A-B versions, does not have time to manage testing himself. EOWG participants are welcome to do A-B or usability testing.

Howard: I was going to say that well, if we weigh them out, the No. 2 is a mild preference.

<shawn> [ Shawn suggests we get input from others in EOWG, and think about the idea of putting out 2 options for public comment]

Brent: I'm not sure that if bringing the question to the survey will not work, but to bring, as Shadi suggested, the resource to the public as the majority, especially as with version No. 2, people can expand/collapse all content and then, people will simply say it. That would be I what I would recommend, i.e., bring version 2 to the public if we don't do any A/B testing.

Sharron: Before we bring it to the public, which might just make more noise. I wonder if we might just want to put it on the survey first. Some of those who are not here today have a good design sense. So, perhaps, we want to do some more internal exploration before bringing it to the public. To see if we reach internal consensus.

<shawn> +1 to getting input from others in EOWG

<Andrew> +1 to getting input from others in EOWG in survey

Brent: That was my opinion, if we could get these opinions. James was quite strong about the expand/collapse.

Annabelle: Andrew and I were having an interesting side discussion. I really don't want this division to hold up production. I do care quite passionately about No. 3. Andrew says that he could do a survey monkey and he could do a local community which would be fun and helpful.

David: I was just trying to think of alternate options. Has there been such a discussion in the past?

Brent: Eric has a good point. He gave the example of the Tips. So, this was his reference to something previous. For the sake of time, we should have a question about these two questions and give a vote and strong reason one way or the other if we add these extra people.

Shawn: Just to answer David. We have not done usability testing on expand/collapse. We have, however, had a lot of negative feedback of pages with a lot of text. We had positive feedback where we had used expand/collapse. We did not do usability testing.

Brent: Keeping this all in mind, we'll have Kevin put together a question on option 2 and 3. We'll see where it lands on the survey with the extra people providing feedback. Everyone okay with that?

Planning and managing web accessibility - prep for survey

Kevin: The next topic is really to introduce a couple of survey questions. I've gone through all the activities and I've put in links to other information on the WAI site and where there is a strong relationship between two activities, I've also added the related activities. Those sections could do with a little bit of thought. Are there are other things which should be in there?
... The other two questions are about taking a step back from the individual pages and activities and coming back to the big picture of the resource. I think just for due diligence sake, can everyone take another look. Ask yourself, is this question complete? Are other activities missing? Especially about projects, and where accessibility fits.
... The next question is that there is overlap with some areas, especially in Sustain. It's clear there will be overlap. How comfortable are you with that overlap? I'll try and fit as much into the question but that's what we're looking at.

Brent: Thanks for summarizing and explaining. So, the meat of the work for next week is to really look at this resource in the bigger picture. What chunks are missing, topics not covered. We just want to ask everyone to spend some serious, thoughtful time on this resource next week and look at it from a high level to help people who are managing web accessibility. I really want to impress on you to look into this in the big picture. Any questions about the forthcoming survey? Some of you have indicated that you enjoy and have skills in the editing process. If you are one of those people who enjoy close editing, we definitely need that kind of help in that type of work. Anything before we close this topic?

Quick ref update

Brent:The next topic is the update on the QuickRef prototype and there's been another group working on the taxonomy. Eric over to you.

Eric: Not too much to say. We are still working on putting the full content of the techniques in there. There's still some resource material I need to go over. Regarding the taxonomy (Sharron, Anna Belle and James) are making progress. They're collecting tags and categorising them. I think Sharron wants to announce so I'll hand over to her.

AnnaBelle:Sharron asked me to post this link to my blog about how we are working and approaching this: Web Design vs Web Development

Sharron: Either Annabelle or I could speak about this. We have been working on the tags taxonomy with a focus on role of content, design, and develop. At our last meeting, we had a thorough discussion about whether the task of layout lay in the developer realm. Annabelle wrote the above blog post.
... The other question (and I don't know the answer), if we adopted this work, would it require a change in UI. Well, this is a question for Eric. Do you see a way to incorporate this work in the UI or would it require a change?

Eric: Basically, it's not problem to add or remove. We might need a drop down. Also, tags would not be universal. You would need a different tag for developing in comparison with design and we would need to do UI changes but also think about how the underlying data model would work. I think it would be quite a lot of work to do. I can't say how much until we have decided that we want to have the 3 components. We now have to go in there and see which categories are really valuable.
... We could fold them into one. It's up to the data and I think it's premature to think about that before we have it ready.

Sharron: Eric attended one of our meetings as a surprise guest and he was very encouraging.

Brent: Well, it was a big task and this is very encouraging. Any questions for Sharron and Annabelle?

Eric: This is hard task to do. The lines are not clear cut. There is overlay. There may be things which might affect some developers. There are a lot of things to consider and it's not easy and we need to be deliberate. It's a fine line to walk. James, Annabelle and Sharron are doing such a great job.

Brent: Thank you, Eric, absolutely. Thank you for figuring how to make it work as well.

Annabelle: Shout out of thanks to Sharron, especially for framing this as taxonomy work.

Gallery of Accessible Web Components

Brent: The next topic is the Gallery of Accessible Web Components. This is a new resource which we are launching. I wanted to give Shadi and Sharron to give an overview of this topic so that everyone understands the purpose of this resource.

Shadi: We often are asked by people - especially those just starting out in accessibility - where can I find an accessible date-picker, for example or some other widget. If you are experienced you may know what corner of the Internet has something like this. The purpose of this work is to provide that platform that shows where those corners are.
... we do not envision to develop or host the resources but to point to them. You might imagine this as a tool that can be replicated.
... we have the funding to create the search function and to point to developed widgets that can be implemented. The resource is meant to be developed to provide the same ability to list and point for articles or authoring tools or other resources that will be useful to people trying to share their accessibility knowledge.

Sharron: I expect that this will be a much-used and quite appreciated resource. It is great to point people to open source widgets like media players and Skip Link menues on GitHub and elsewhere that are pre-configured for accessibility.

<Vicki> Yes, it is a great idea.

Shadi: So the widget you spoke of, Sharron - in the future you could add that to the list maintained by WAI through this tool.

Eric: I have read through the survey feedback. It was helpful, especially comments on the Overview page. Some comments on the icon theme, of course it is still very early. No red flags as yet, nothing to discuss unless someone has had thoughts since the survey closed.
... we want to collect frameworks, templates which literally means we need people to contribute. Kind of like the taxonomy, we will rely on a small sub group of EO to focus in on filling in the fieldsand start populating the tool. It will also be a good way to get feedback on the UI. Our goal is to have about 20 listings before we list publicly. That will atract more contributions which is very important.

Brent: Thank you for the detail, Eric. To reiterate, we are looking for accessible frameworks, templates and widgets to begin. I would like to call for volunteers at this time to lead that effort.

<Howard> I'm willing to do this

<Andrew> happy to help

<AnnaBelle> i'd be happy to help though i may need to back away in a few weeks cuz of a big project in pipeline.

Sharron: What is the process to submit? Should EO submit to the sub group or simply put it into the tool?

Eric: You can email me or use the tool to submit your entry

Brent: I challenge everyone to find one and add it to the tool which will also help us look at usability and give Eric feedback about how the tool itself is working

Shawn: I think that Eric will provide guidelines on submitting tools, that will be coming up.

Shawn: a reminder that we have a wai-eo-editors mailing list at wai-eo-editors@w3.org. I encourage you to copy that list when you work on a group or submit a tool or have anything that needs to be archived and findable that is not sent to the entire EO list.

Eric: There will be submission guidelines which we will review in the group as well. Those will be along soon.

Brent: Eric will take a first pass at the guidelines and then have EO volunteer to help polish them. So people who want to submit will have clear guidance about what the tool is for and how to determine what is an appropriate submission, and how to submit.
... please submit the the group of AnnaBelle, Andrew, and Howard or to the tool itself.
... we had a brainstorm question on the survey. In thinking through the ideas that people had, Shawn has agreed to walk us throughthose ideas.

Shawn: Thanks for the brainstorming, great place to start

Naming the Accessible Components resource

<shawn> https://www.w3.org/2002/09/wbs/35532/EOWG-weekly-201601/results#xq10

<shawn> WAImart - The Component Store

<shawn> Repository of Accessibility Resources (ROAR) already has "theme" song (by Katy Perry)

Shawn: I wanted to point out 2 things (above)

<Vicki> :)

<yatil> +1 to ROAR :-)

Shawn: looking at two types of words

<shawn> Repository

<shawn> Library

<shawn> Catalog

<shawn> Directory

<shawn> Collection

<shawn> Compendium

<shawn> Hub

<shawn> Bank

<shawn> Cache

<shawn> Co-op

<shawn> Museum

<shawn> Toolkit

<shawn> List

<shawn> Gallery

<shawn> Examples of...

<shawn> WAI Finder for...

Shawn: this is the first batch of one word that describes that it is a collection.

<Andrew> -1 to repository (nothing held by us)

Shawn: from this list, does anything particularly jump out as pro/con

<Vicki> -1 to Cache, Co-op, Museum, Repository

Brent: +1 to Andrew's point. Any word that makes it seem it is heldby us should be avoided

<Andrew> +1 for catalog, directory, compendium

<Andrew> -1 to repository, bank, collection (nothing held by us)

<Howard> Like library or catalogue

<shawn> What about things that do work?

<Vicki> +1 for Library, Hub

<shawn> What about things that do work?

<AnnaBelle> Museum sounds antiquated; no vote no on it

<Andrew> -1 for Library (also implies we have the resource)

<Vicki> +1 WAI Finder

+1 WAI Finder

<AnnaBelle> Love hub

<Howard> I like wai finder

<yatil> WAIHub - like Github?

<Andrew> +1 for catalog, directory, compendium (pointers to resources)

<Howard> Catalog is good

<Brent> +1 catalog, hub, collection

<yatil> WAIhub sounds like it is from WAI , and the github connection emphases that.

<yatil> +1 directory, catalog

Shawn: Let's go back and look and + or - ...

<AnnaBelle> +WAIhub

<Vicki> +1 WAIhub

<AnnaBelle> +1 Compendium

Sharron: like the WAI connection...WAI Hub or WAI finder

<yatil> +1 for ROAR, +1 to ???hub, ResourceHub?

<Vicki> -1 catalogue (sounds like a book)

<Vicki> +1 ROAR

<yatil> Accessibility Resource General Hub --> ARGH

<shawn> (reminder: not "web components")

<shawn> accessibility resources

<shawn> resources on the web

<shawn> code components

<shawn> web code

<shawn> user interface components

<shawn> components on the web

<shawn> interface elements

<shawn> web elements

<shawn> web assets

<shawn> templates

<shawn> tools

<shawn> ...more?

Shawn: Let's look at the second part - the word or phrase of what is being collected and served

<Andrew> compendium - "a collection of concise but detailed information about a particular subject"

<Howard> +1 to wai finder, catalog

<AnnaBelle> +1 Hub

<Vicki> +1 Accessibility Resources

Shawn: reminder that we are trying to avoid components since it clashes with another W3C resource.

<yatil> -1 to assets (CSS/JS), elements, * components

<Brent> -1 to interface elements

<Vicki> code components, user interface elements, templates = too restrictive perhaps

<Andrew> +1 accessibility resources

Shawn: Currently this looks at widgets, templates, and frameworks. In future we may expand to inlcude articles and tutorials.

<Andrew> +1 Accessibility Resources (given future potential)

Sharron: That was not how I understood what Shadi said...can you clarify?

<kevin> +1 to 'resources' - it is broad enough to cover the many different elements that are being thought about

Shadi: What we proposed was to make things more flexible and simpler was to create a second instance for future expansion. It could still be under one umbrella but the tools would be distinct...one on components, one articles, separate interfaces that work the same.
... otherwise the search function becomes more complex. Prefer to keep it as separate resources with an umbrella overview page.

<Andrew> -1 assets, elements, components (too restrictive)

Eric: We spoke about this quite a bit. We want to keep it open-ish but still leave the option open to re-use the design and search function for polcies, articles, etc.

<Vicki> +1 for "Accessibility Resources" as the overarching name

Shawn: So we may end up with something like "Accessibility Resoruces" as an overarching name with sub-categories and specific types of resources that are organziaed separately.

<shawn> "WAI" in the title?

<shawn> "Accessibility" may have better SEO than "Accessible"?

Shawn: The issues with having WAI in the title...what are those?

<AnnaBelle> Shawn - could you speak to that?

<Andrew> as long as we don;t imply they are WAI resources

Shadi: A reminder is to point to non-WAI resources and that must be clearly communicated.

Andrew: Yes, agreed that we must be very very careful that we don't imply these are not created by WAI.

Sharron: WAI finder seems to address that.

<Brent> +1 to WAI not being included

Shawn: Will take this intro to survey...back to you Brent.

Reminders

Brent: Thanks for the discussion Shawn, a reminder to pay attention to the F2F survey, your availability and the deep read through of Planning and Managing. Please take time with it, give the resource full attention and consideration. We will also have questions as noted on the names. Thanks so much everyone and all of your stepped up effort in support of developing these great resources.