QuickRef prototype

<shawn> https://w3c.github.io/wai-wcag-quickref/

<shawn> survey https://www.w3.org/2002/09/wbs/35532/EOWG18Dec2015/results#xqr4

Eric: Had public review, receieved survey result, all positive. No one objected to the proposals so those remaining issues will be closed. The one open issue is about simpler language, and we will focus on that in the future.

<scribe> ...done now with public review comments, thanks to everyone for your attention to that in the past few weeks.

Shawn: Questions?

Planning and Managing Web Accessibility

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

<shawn> survey https://www.w3.org/2002/09/wbs/35532/EOWG18Dec2015/results#xq5

<shawn> Prototype with Plan content all on one page http://w3c.github.io/wai-dynamic-planning/plan/full.html

Kevin: Been through survey results, only one comment to be resolved. Several useful comments and suggestions have been processed. The one thing we want to talk about is David's comment

<kevin> https://www.w3.org/2002/09/wbs/35532/EOWG18Dec2015/results#xq5

Kevin: His concern was that each section's content would be better served as one page.

<shawn> Prototype with Plan content all on one page http://w3c.github.io/wai-dynamic-planning/plan/full.html

David: It is a classic case of deciding how to lay things out. I noticed as a user I was annoyed by the need to continue moving from page to page. Not enough content to justify series of pages for the activities.

Kevin: Relates as well to Andrew's comment about multiple side navigation boxes.
... background is that the original idea was to have small bits of interactive, dynamically constructed solutions to specific scenarios.

David: I sensed and felt that there was a missing functionality...when I saw it was just prose, it bothered me. That fits.

Howard: Another option is to have a print version as an alternative for those who need it.

Susan: I want to verify...we are talking about putting all of the topics in one section on just one page?

David: Yes

<shawn> Prototype with Plan content all on one page http://w3c.github.io/wai-dynamic-planning/plan/full.html

Susan: Not all of the sections are so short, we could get to a point where it is overwhleming

<SusanHewitt> What about giving both options? (e.g. link to "view on one page")

Shawn: Here is a mock-up that Kevin made. That is a good point Susan. We plan to get the first version done in the next few months, and though we may revisit and add content, that is not the plan at this point.

<kevin> [Note that prototype is very draft in design and functionality]

Shawn: we also talked about the possibility of doing it both ways for printing purposes and for those who have different preferences. So there would be an overview page and four sectional pages. We can look and see if the one page option is best for most users, we could go that way or consider other options. Here is the mock-up.
... please take a look and let's discuss. Kevin, there would also be links to Related Activities and More Information in each section?

Kevin: Yes that is right

Shawn: And there is a possibility as well for expand/collapse for each section

<SusanHewitt> prefer both options given to user... or expand/collapse

Sharron: Kevin, is this the longest one of the sections?

Kevin: Yes, I deliberately picked the section with most content.

Shadi: And to look at the expand/collapse, there is How People with Disabilities Use the Web and a few others.

<shawn> for example http://www.w3.org/WAI/intro/people-use-web/principles

Howard: The only thing I don't like is that there is no list of all items together...perhaps the expand/collapse would address that.

Shawn: Or have a list at the top

AnnaBelle: I like the idea of one page, like what is here now and strongly dislike the idea of expand/collapse. Here it is not really even needed.

<George> + for long page

Andrew: I like the idea of one page, I was going to ask if there would be much addition to the text. I would not be keen on expand/collapse unless it was handled differently with a summary line for each section.

Shawn: Support seems to be for one page, list of subtopics at top, expand/collapse, Andrew suggested would need short summary. Expand/collapse function could be expanded by default.

Susan: What is the objection to expand/collapse?

<shawn> ftr, I actually really like expand-collapse

AnnaBelle: It adds a layer of complexity. People may not know they are in a default state and what the options are. I always fall on the side of simplicity. With the rise of mobile, people scroll much more naturally.

Susan: Although we can never infer what users know, I see expand/collapse used extensively.
... I think it would be odd to have it default to expanded.

<Andrew> expand/collapse works on easy-checks page as it hides specific test stuff within each test discussion

Shawn: The proposal is to combine the various subtopics of each section into one page (undecided about expand/collapse as yet)

Shadi: So all four pages would go into one single page?

Shawn: No - five pages. One for each section and one overview page.

Kevin: I am hesitant to go down the route of putting the full list at the top.

Shawn: is it not similar to the Getting Started Tips?

<shawn> gettings started tips with list at top http://www.w3.org/WAI/gettingstarted/tips/writing.html

Kevin: OK,with that understanding, I have less concern

Shawn: Proposal is there would be five total pages, each page would have an "on this page" list at the top.

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

<davidberman> +1 to Howard's tweak to include in-page navigation links

Howard: Why not just keep organization like this...and then when you select any one of these, you move further down into the page instead of a new one?

<Andrew> +1 to considering Howard's suggestion

Howard: that keeps the short summary and is clear.

Eric: I am wondering why we don't use the approach - the activities box on the right works well, does not take up too much space.
... rather than such large and distinct, long headings etc. I am happy with the planning box on the right and would not like to see it go.

Andrew: I found that having two menus - one that references the entire resource and another below that lists links to subtopics hard to quickly pickup and use effectively.
... having a floating menu might be less interfering since it scrolls with you.

<James> +1

Susan: I think the floating menu is too complex and potential usability issue./p>

<Howard> http://w3c.github.io/wai-dynamic-planning/plan/full.html

<davidberman> +1 (floating menu seems overkill for a page of this nature)

Howard: If we put the subtopic menu on the right and nothing on the top, it will get lost. There needs to be something at the top that tells people this is what is on the page.

Shawn: Any thoughts about how to format top info?

Sharron: +1 to Howard's suggestion for keeping the current format but leaving detail on one page instead of opening new one.

<George> +1 to howard's solution

David: No, if we were to include the list at the top, it should only be a short list

<Andrew> +1 to KISS approach (simple menu)

Shawn: The layout of two columns may be too complex, but the information is useful to orient people to the content.

Howard: I will go with consensus. However, this is not like the tutorials where people may be looking for a specific thing. The reason I like the topic accompanied by a sentence setup is that this is a process and having it laid out this way communicates that.

Sharron: +1 to Howard

James: Howard convinces me that the navigation model can reinforce the idea of the process itself. Perhaps make the heading the short sentence as Howard described and then expand that section. So the expand/collapse would work that way.

AnnaBelle: I have the same expand/collapse issues, unchanged

<Andrew> again - are we being too clever and making thing too complex for the reader?

James: Some people want the quick version and if you want more detail you can expand the section. It is wholistic, allowing people to see the whole process and to drill down as needed. Giving people that short summary and letting them move along or go deeper by activating the link and having it expand in place.
... It combines elements of both options.

Shawn: It would be common for people to skim the whole thing the first time and then return for detail in specific sections as needed later.

Sharron: I very much like this approach - presenting an overview of each part of the plannning process with options ofr exposing greater detail. I had been leaning away from expand/collapse but seems like in this case, it is the perfect place for this type of functionality.

George: I like the way James has explained it. Thinking of users who return, it seems they would be able to quickly orient to what they specifically are looking for.

Shawn: Kevin or James, can we see a prototype of this idea?

Kevin: Sure, can put that together.

Shawn: That would give us a chance to see how complexity may be added and whether it clarifies or makes less clear?

<Andrew> thanks kevin - would be good to see prototype before finally deciding

<SusanHewitt> +1 to andrew

AnnaBelle: Yes, great I love the idea of a prototype and maybe that will banish all concerns.

RESOLUTION: The Planning resource will be five pages - an overview and one page for each section, inlcuding all subtopics and related activities.

Shawn: We published a survey on this resource that asked for big picture comments. The earlier you have comments the better.
... as you drill down, please continue to add big picture comments

Getting Started Tips

<shawn> additional comments https://github.com/w3c/wai-quick-start/issues/297#issuecomment-169660739

Shawn: The history on this is that a public comment on Tips for Designing expanded the Tip considerably. We have been refining how to address it. The recent survey produced a few additional comments

<shawn> http://w3c.github.io/wai-quick-start/designing.html#include-image-and-media-alternatives-in-your-design

Shawn: based on those, there has been another revision.
... minor changes to wording, the example itself is changed, etc. Any comments on those chages?

James: May people think they need a text link (that can interrupt their design) when in fact they could use the AD icon.
... maybe make one of those an icon?

Eric: We *do* have the closed caption icon although it may make sense to add another one to call it out more clearly and to demonstrate the proper way to implement the icons.

Shawn: There are not yet well established icons. It would look really nice next to the caption icon. But that would put them in the video player, making them harder to find, so I am conflicted.
... instructions say 'visible link' which insinuates text so if we change it to an icon we may need to reconsider the phrase.

James: Again, there is a fairly well-known icon for AD, we use it in my shop. I am not sure how to make it work, but I just wanted to make sure we consider designers needs for visual elegance.

<James> http://www.hammillpost.com/wp-content/uploads/2012/12/audio-description.png

<James> http://www.hammillpost.com/wp-content/uploads/2012/12/audio-description.png

<Andrew> also https://commons.wikimedia.org/wiki/File:Pictograms-nps-accessibility-audio_description.svg

Shawn: Where would the icon be found?

James: We put it before the player - two separate videos
... the step before you get to the player.

Shawn: Can you send an idea for how we might do this?

James: This is a small simple example, my concern is only that it will lead designers to believe they must add text link.

David: We too use two different videos and have a text link that allows people to understand that it will be an entirely separate video player.

James: another possibility is the modal window that allows presentation of links. It may communicate enough of the flexibility to solve the problem.

David: I agree, sometimes the designers may be more amenable to an expand/collapse presentation.

AnnaBelle: I really don't like the idea of expand/collapse here either.
... I appreciate the need to address the issue from a designer's perspective.

<James> +1 to AnnaBelle

<shawn> +1 to AnnaBelle

Shawn: I agree with AB about expand/collapse in this case.

<yatil> +1 to AnnaBelle

Shawn: We do not need to show the media player, so we should not get stuck on that.

Sharron: this example is text link, but that is not the actual requirement. Since other methods are acceptable, perhaps that could just be made clear in the instruction. That icons can be links, etc.

George: I suggested to add a sentence - short clarification that there are other possibilities for presenting the links,

<kevin> +1 to short clarification

Shawn: The fact that it says "visible links" combined with the text links in the example may too strongly suggest text links. James, can you work with Kevin on that?
... At the end of the call we have planned Middleman training. Making changes in GitHUb can be easily veiwed with Middleman. Works well with Mac not at all well with Windows. So for a time chack, who else is interested? if you are, can you stay ?

Susan: Yes I am interested, but can't stay today.

<davidberman> Middleman: I'm out, because I'm addicted to Windows for my github use.

James: If you don't know what you are talking about, now you are using markdown that allows only changes to text. Kevin will show us a tool that allows more extensive changes.

Shawn: We will see if we can at tleast get an intro today and then reschedule.

<George> I am interested...

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

Gallery of Accessible Components

<shawn> requirements: https://github.com/w3c/wai-components-gallery/wiki/requirements-analysis

Eric: Here is the link, it is a project that has been in queue for a few months, basically a collection of compnenets from all over the internet. For example if you have made an accessible date-picker, you can post it.
... there is a link to the overview [draft] page

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

Eric: and please understand that there is no design love applied as yet.

<yatil> https://github.com/w3c/wai-components-gallery/wiki/use-cases

Eric: It is not that WAI will actively collect but that we will accept contributions, will be reviewed and then posted.
... currently thinking templates, widgets, and frameworks.
... everything will be tagged, will allow vendors to post.
... it is a crowd-sourced thing so we will have opportunity to report
... will use WP comment section to allow curation. Want to pull in things that can be accessed via puvlic info like GitHub. That is the basic plan. This is the first pass at a framework and we will open for general comment and naming.
... in the survey.

Andrew: Is W3C planning to host the materials or can people such as Canadian gov to continue to host but merely link?

Shadi: Yes the plan is not to host but only to share collections or individual components that they may have.

<yatil> Web Accessibility Evaluation Tools List

Shadi: similar to the Tools list, it will provide info about the component and a link to the resource.

Andrew: CA Govt has an extensive collection already - http://www.tbs-sct.gc.ca/ws-nw/wa-aw/wet-boew/index-eng.asp

Shawn: So please review the requirements and the rough wire frame mockup. Looking at what it does, don't worry about visual aspect for now.

<yatil> https://github.com/w3c/wai-components-gallery/wiki/Naming-the-Resource

Shawn: We will ask about the general approach and name in the survey, here is background on naming

Shawn: cast your net wide on naming, keep in mind that it is nice to have a short name or acronym.

<Andrew> catalogue

<AnnaBelle> showcase

WCAG-EM ReportTool title

Shawn: Having spent quite a bit of time on it, nothing has clearly emerged as a good replacement title. Wanted to propose that we leave the title as it is with awareness of the subtitle.
... in the survey result, the one that came up the highest was "Builder" but there were translation issues

Shawn: Proposal is to leave the title unchanged
... discussion? objection?
... I am fine with leaving it despite my original concerns.

<SusanHewitt> I don't feel too strongly on this

<yatil> +1 for not changing

Andrew: I echo that

+1

<AnnaBelle> +1

<James> +1

<davidberman> +1

<SusanHewitt> +1

<Howard> +1

<George> +1 not changing

<kevin> +1

RESOLUTION: The title of the WCAG-EM Report Tool remains unchanged for this version.

<Andrew> +1 (can live with no change)

Work for this Week

Shawn: Survey will include Gallery, can begin that consideration any time. Depending on when we get the one page Planning and Managing resource, that may be on there, may have GSTips as well.
... may add to the survey so stay alert. Update availability.

Middleman Training

Shawn: The training will be recorded
... official notification that from here forward, the meeting is recorded.

<kevin> https://middlemanapp.com/basics/install