Accessible UI Components list

<yatil> https://www.w3.org/blog/wai-components-gallery/

Eric: I have made several updates to the interface, mostly cosmetic changes. Including...on the left side, pulled out the appearance of the text from QuickRef and applied it here.
... added some styling to left side, highlighting various components - would like your reactions on that.
... on the bottom I have added components submission sidebar box that has the button more highlighted, easier to find.
... in right column Shadi feels we do not need explanatory text, info is quite compact. So I removed the link to the detail page. Have aligned presentation with Evaluation Tools list

<yatil> https://www.w3.org/WAI/ER/tools/

Eric: What is missing as yet in functionality is the Share on each item, will be added later. Added standard WAI footer and on top we have a link to disclaimer page which was drafted last week and need approval for the text.

<shadi> +1 to howard - looks really nice eric

Eric: Next week we will ask for a very close look and the ability to have it ready to publish by the end of the month. Will be a survey.
... your questions or immediate reactions?

Brent: Some have development on GitHub - if they do not have that link is it because it is not on GitHUb?

Eric: Yes we we use the GitHub API when that is provided.

Howard: Looks so nice, Eric what a difference! A couple of things struck me...should there be an icon next to the tool that indicates it goes to another page off site? Also wondered if the submission button should be more prominent, maybe closer to the top.

<Susan> +1 to Howard on external page notification

Howard: otherwise it is quite scannable, very nicely presented.

Eric: Thanks for that feedback, an icon makes sense. The submission button is another question. On the Eval Tools page we have it closer to the top, will consider that.

Howard: Is this only a subset of what has been submitted?

Eric: Yes, the pagination is not yet in place and some components are still being reviewed.

<Zakim> Andrew, you wanted to ask more about GitHub

Howard: I could see the relocation of the submit button to a couple of other more prominent places on the page.

Andrew: Following on about GitHub, it seems the GitHub links are not consistent - one from the Canadian government is not linked to the GitHUb source - what happened?

Eric: It is how it was submitted, if the submitter did not provide it, we do not always know. I will make a run through the ones we have now to check for GitHUb support.

Susan: The GitHub links are visually confusing, is it really necessary?

<shadi> +1 to susan

Eric: But that is the point, the GitHub repository actually is quite relevant to the tool. If I search for a component I would certainly want to know of it.

<shawn> +1 for putting the Github info within the box, and not as a separate line

Susan: I don't get the relationship to us and our service to point to these. Can we revisit this, don't mean to hold up the meeting.

Eric: This is an important consideration.

Shadi: We may have a solution in the Tools list. What might be interesting to you may be different that what is important to me. So maybe we could mimic the way the detail of the listing can be hidden and expandable. I think we need to consider what is the most important information and then cascade the rest of the detail.

Eric: We could hide developer, license and GitHub info.

Shawn: The problem with this is the way it visually stands out. If instead it is a regular text line that looks like everything else rather than calling it out so prominantly. Rather than an expand, just present it in simple text.

<Sharron> + 1 to Shawn's suggestion

<Susan> +1 to Shawn as a good direction to go for now

<Brent> +1 to Shawn info in plain text

<yatil> -1 for plain text - so boooooooring ;-)

Howard: I like the line and information, and agree with Shawn that the reverse text presentation is distracting and to make it less so is good. See no need for an exapnd, just tone down the presentation of that bit.

<Andrew> info is useful - just shouldn't be quite so distracting.

Susan: We are all saying put it plain text, if it is too boring maybe consider bullets to break up the text a bit.

Shawn: If I choose to view the disclaimer, it persists, I can't get rid of it. And what about the difference between buttons vs checkboxes in QuickRef vs here?

<Susan> Why is not a link?

<yatil> [Shawn proposes show hide to be a show/hide]

Shawn: could show/hide the disclaimer.

<Susan> is that not a 4.1.2 error?

Eric: I am still considering the button vs checkbox question.

Shawn: Whether they are in an alphabetically arranged line or in a list makes a difference in how findable the information becomes and has impact on how users process it.

Eric: I could have show more list to provide a bit of wiggle room, thanks for that input.

Shadi: I had quite a bit of trouble with having apply filters at the bottom. It is significantly different from how it is done on the other tool list, quickref. Why are we choosing a different design here? Why not re-use the design of the Tools list wherever it is possible?

<yatil> [Shadi asks Eric to reprogram WordPress]

<shawn> +1 to prefer how it works in the tools list

<shawn> for tools list - like that filters automatically when click

Eric: There are many fewer choices for one thing. We do not need the expand/collapse because of that. Of course I can do it more like the Tools list, but it is a different system and I have less freedom within the constraints.

<shawn> bummer it's not easy with this dev tool

Shadi: So it is a technical issue. That makes sense, although it is unfortunate, would prefer not to have to apply filters with a button. It is a bit clunky, in my view.

Susan: The disclaimer info why is it a button? I don't see why, it is not in fact a button in function.

Eric: I agree, I can change.

Susan: I like the look and don't think that the QuickRef looks as clean as this does. I understand Shadi's point, and it would be good to have it visually aligned. As we move to a redesign of the site, we want the tools to match, to look and operate the same.

Andrew: One of the possibilities is at the bottom of each section...and wondering what is our MVP? Why not release it and work on improvements as we get more public feedback?

<shadi> +1 to andrew - bring the button closer

<shawn> [MVP = minimum viable product]

Andrew: if open issues do not prevent people from using the tool but only nice to have usability improvements? can we release as is and update as more data is available rather than guessing.

Eric: The questions from today seem pretty critical to me actually.

<shawn> -1 for releasing yet -- some of these issues I think need to be fixed before release

<yatil> -1 for releasing, needs some rework.

<shawn> +1 to moving one for now

<Susan> and -1 to releasing

Brent: maybe we can wrap in the judgement about the critical nature of the issues that are being raised. Also remember that we will be gathering user feedback at AccessU in just a few weeks. Can we push on?

<Susan> +1 to Brent

Survey on submission criteria for UI Components

Eric: This was generally approved. There were a few requests for rearrangement of sentences and so will likely keep it mostly as it is now. May ask for more input later on.

<yatil> https://www.w3.org/2002/09/wbs/35532/EO-Weekly-11Apr2016/results#xq4

Brent: Thanks for the great discussion on this, we will have more opportunities for comment before publication.

Improving the Accessibility of your website

Brent: We are getting close to releasing the Planning and Managing guide. Along with that are two related documents, this one and the Policies doc.

<shadi> https://github.com/w3c/wai-planning-and-implementation/issues/62

Shadi: The reason we are bringing this to the group is to consider the issue that Shawn raised. Most of us accepted the document however these concerns are valid and deserve consideration. Not to surprise anyone by changing this, we wanted to bring the proposed changes to the group.
... most has to do with tersification. Let's read it quickly...

there are many comments and good examples of how to shorten the document. Perhaps even more interesting are the suggestions to remove entire sections - such as the proposal to remove the first pass check, quick fixes before doing the full evaluation.

scribe: my concern is that if we remove this, are we removing best practice?

<yatil> [Skimmed the document and read Shawn's comments and I support making the changes]

<yatil> [But doesn't feel an immediate need for it, tbh.]

Susan: I definitely see Shawn's point and brings me back to my original concern. I feel like this page duplicates information found elsewhere, if we want a "Quick Fix" page - eight sections doesn't help me now however much they are shortened. I can see that the changes are appropriate but does not address the foundational problem - which is duplication and lack of clarity about what is this for and how is it different from all the other related items that deal with this stuff.

<shawn> [ /me would like to hear more about what Susan thinks *would* make this document useful?]

Shadi: Kevin and I were considering a last minute need - people who are in the middle of a project and learn they need to consider accessibility. How can we help them now and let them know that they will probably need to revisit later?

Susan: I don't disagree that this is a valid use case but I do not think this document does that.

Shadi: Can you give this more consideration now or doing it over the weekend?

Susan: Yes I will do it today while it is fresh on my mind

Joy: Clarification - is the goal to give people low hanging fruit?

Shadi: Yes here are a few things you can do even though it is not enough and must be reconsidered more thoroughly later on.

Brent: I was thinking the same as Susan. If I was looking at this or someone sent it to me - I would think OK, this is what I need to do for accessibility. I would not understand that I need to revisit or that this is not a complete guide. It needs more punch around that issue.

Shadi: Needs to be repeated throughout the document, to continue to remind them.

Andrew: if the target is to give quick fixes, then this document is far too complex. Need to help them select what some of the easy fixes might be.
... concur that simply tersifying does not address the central issue.

<Zakim> yatil, you wanted to say what I noted above, also probably just intro + quick start tips and to say that we might ask too much, probably just "get the a11y firefighters" would do it.

Eric: I see Shawn's points and wonder if we need to address this right now or if we can come back to it?
... if someone comes and asks me, I would advise them to get an accessibility firefighter to guide them. It will be hard and actually not even realistic to say 'do these quick things' if they have no understanding of accessibility. Need to tell them to step back and get better resources. Can't really give them useful resources for this use case.

<Zakim> shawn, you wanted to say I think it's more than just "low hanging fruit". fyi, I think this is some of the key info <https://www.w3.org/WAI/EO/Drafts/retrofit/Overview.html#prior>

<Susan> +q very quick comment

Shadi: I think this is what kevin's position was... don't have to assumne however that this is a small org with no resources.

Shawn: Probably you need to point to a firefighter but you need to give them enough info to ask the person who is helping them to be focused on what is most useful. Also I think this is more than the low hanging fruit. Some key info is how to help them understand how to prioritize.

Susan: I think we must recognize the reality of what people are looking for. There was a blog post from a girl getting started in accessibility who said, I just cannot go to the W3C because the stuff there is just not useful - too dense, too long.

<shawn> +1 this document should be terse, short, to the point

Susan: The direction of going to the low hanging fruit misses the point - we need to think of people who need quick help. We need to give them clear focused direction.

Eric: Should not just say - go get help. To truly be helpful however, they will need very specific information. We do not know enough about each situation to provide that. What I see is that this document is trying to have a very pure approach to this problem but if you really consider quick fixes it will be down and dirty and not at all this clean and pure. It is likely to be quite messy in the end.

<Andrew> +1 to needs to be more pragmatic for use case

Eric:...so it would be better to get them in, explain high level what is accessiiblity and point them to some of the beginning resources, and if that does not make it more clear, you may need external help.

Shadi: There seems to be agreement on the use case, agreement that this doc does not address that use case, general agreement with Shawn's approach, understanding that we need to get more pragmatic rather than ideal.

Brent: I think that captures our shared understanding.
... anything else?

James: It might be a solution to the wordiness. Why not take an approach like a FAQ list...ask some questions about general situations and then "what do I do now" kind of question. Provide quick solutions.

<yatil> [could also think of multiple pages, or having a show/hide]

Shadi: Do we have those questions generic enough and yet specific enough to be actually useful? If you have suggestions for those questions, please do put them in GitHub. Do I need help with evaluation, with fixes, with all of the above? I will consider and take another pass.

<shawn> [ /me like the idea of thinking what the questions people will have (although not convinced of FAQ format ]

Acessibility, Usability, and Inclusion

<Brent> https://www.w3.org/WAI/EO/wiki/Accessibility_and_Inclusive_Design/Requirements_Analysis

<shawn> https://www.w3.org/WAI/EO/wiki/Accessibility_and_Inclusive_Design/Requirements_Analysis

Shawn: At F2F we just kind of stuck this resource out there. This is another case where we needed to step back, look at requirements, and get in sync as a group about what we are doing with this one.

Shawn: This requirement is for an audience that is quite focused, specific, and small.

<Susan> Glad to see the point that we are not defining any terms

Andrew: This is something we have talked about for a long time, needs to be published quickly, so let's keep it tightly focused and quite specific.

Shawn: We want to be sure that we have a shared understanding and agreement on the requirements. Good time to express any inital concerns or questions.

Howard: There is a movement of inclusive design for online learning. These questions are common and I wonder how you can discuss without making difinitions, distinctions. Seems that there is a contradiction to say we can do this without definitions of some sort.

Howard: In academia, you start with a definition even if you say this is *my* definition. Otherwise you court confusion.

Shadi: It is confusing how it is written. There is a difference between defining, setting parameters, etc. The idea is to describe the scope of each of these areas rather than a formal definition (and how they overlap)

<Susan> huge +1 to shadi

Susan: I think one of the things we spoke about is to get away from saying the same things over and over and over everywhere. Rather it would be OK to point to definitions made elsewhere.

Shawn: So maybe tweak the requirements to say we are not trying to create a new, formal definition here but are trying to help people understand the differences.

<Susan> Sounds good shawn

<shadi> +1

<Andrew> and understand the complementarity

Shawn: will ask in the survey to approve the requirements, so speak up now with any concerns or questions.

James: This reminds me of a blog post or informative essay. My only thoughts then would be to consider that direction when writing it and try to include more than just words, (Venn diagram, etc). We need to create content that is interesting and engaging. Begin to change the theme and tone as we move forward.
... a tone or theme that are educational, engaging like blog posts. Structurally different, I am encouraging a more conversational tone in mind. A good experiment and allow people to link to this and make people include it in the set of resources I like to read and share.

<shawn> +1 to like blog post type thing not a typical WAI resource

<Susan> [Link to previously mentioned blog post about resources. I found this link via speaker bios for OSCON. We need our resources to be something speakers want to share at conferences: http://ispeakincode.com/wp/?p=49 ]

Shawn: Anything else on the requirements?
... big picture on this relates to a document in the past with slightly different requirements. One that encouraged crossover between accessibility and usability practitioners.
... we have a couple of documents to support that previous requirement. We would like you to consider 1. the requirements analysis 2. consider how this meets that requirement 3. consider practical tips, do they belong here, or somewhere else, and is it a priority?
... do we have a document with two parts? or does all the info belong in just this one?
... will be a good excercise to do something entirely different, short sweet focused.

Resource management process

Brent: On a weekly basic, EO has a planning meeting where editors, chairs, staff meet to plan the meeting. Look at survey results, priorities to plan discussions, etc. Have considered that since RMs will be seeking feedback and asking for survey feedback, the planning meetings are open.
... we want you all to understand that when you have an active resource that you want to push through, get group feedback, and do the updates you are welocme to attend the planning meeting so that we can integrate those questions/discussion items into the meeting planning.
... want RMs to understand how to move your resource through the EOWG consideration process.

Brent: meetings are generally held at 8 am Central time on Thursdays, is generally a quick meeting and when you bring a resource for consideration you will only need to stay for your discussion item.
... welcome your questions or suggestions for process
... if you know that your resource is time sensitive, let us know even sooner. The more notice the better.

<shawn> generally need to know a couple weeks in advance when want to get it on an agenda

<shawn> e-mail that goes directly to chairs & team contact -- and not publicly archived: <team-eowg-chairs@w3.org>

<James> https://www.w3.org/WAI/EO/wiki/RDLC

James: I had one other thing to ask, can we include an inputs section in the RDLC?
... I redid it based on the various comments we got. An open question was what Shadi meant by inputs.

Shadi: Minor suggestion, this approach reminded me of one where there were very specific handoff between phases. We have specific outputs - the deliverables. Thinking that we need some inputs at each stage as well - like a dessimination plan for the Outreach phase, etc.
... need to know what we need in terms of resources to complete the phase.

James: OK good to know and will follow the process just outlined by Brent and keep working it.

Face to Face in 2016

Brent: Will have an agenda up for the AccessU f2f. Choosing resources that we want to use to conduct user feedback sessions and will integrate that into the agenda.
... also please consider the opportunity for the f2f at TPAC in Portugal in September. Need more confirmed attendance for that.

<shawn> Sharron: use to have more active European participation (e.g., Helle, Liam, Sylvie) and would get good attendance at TPACs in Europe. but not much right now

<shawn> ... please be as definitive as possible in the survey

<shawn> we need to get a good idea of who would be ablt to go

<shawn> .... we need to make a go/no go decision whether or not we're going to be able to have a viable f2f. Also please let us know ... anything you need from Chairs to support your ability to travel to TPAC.

<shadi> [maybe opportunity to engage more EU participation if you meet in the EU (paired with some outreach and promotion)]

<yatil> +1 shadi

<Sharron> +1

Shadi: Is the May f2f geared to user testing and the feedback for that?

Sharron: Yes my expectation is that we will test resources, gather data during the conference period, and then focus in on analyzing and using that date to plan for improving them.

Shawn: We may change the focus for TPAC to liaison with other groups and outreach in order to fulfill that part of the charter.

<shadi> [engage with W3C membership and recruit more participants]

<Andrew> [inreach to W3C membership at TPAC]

<shawn> outreach to TPAC community on WAI & EOWG work!

Brent: Thanks for everyone's time, have a good weekend.