Education and Outreach Working Group Teleconference

<shawn> Optional Meeting on WAI Site Navigation ReDesign

<shawn> agenda at https://www.w3.org/WAI/EO/wiki/EOWG_Meetings#Optional_Redesigned_Nav_Meeting

<Sharron> trackbot, start meeting

<trackbot> Meeting: Education and Outreach Working Group Teleconference

<trackbot> Date: 25 August 2017

<Sharron> Agenda: agenda at https://www.w3.org/WAI/EO/wiki/EOWG_Meetings#Optional_Redesigned_Nav_Meeting

<shawn> addressed comments & open comments https://lists.w3.org/Archives/Public/w3c-wai-eo/2017JulSep/0037.html

<shawn> https://www.w3.org/WAI/EO/wiki/EOWG_Meetings#Teleconference_Logistics

<Sharron> Scribe: Robert

<yatil> scribenick: rjolly

RESOLUTION: We'll go with Nav ALT 3

<yatil> Alt 3: https://docs.google.com/spreadsheets/d/1pqcSChcWZwTShpov34jDfvX2E-jW6_M5khV38D53Qqk/edit#gid=887243996

Duplicates in Navigation

<shawn> Keep in mind that having page in multiple primary nav complicates breadcrumb, and the sub-pages can like to these as related documents, e.g., the sub-pages linked under Train & Advocate can point to the Business Case, so maybe not need it in the nav, too...

Laura: Why are we duplicating things in the nav?
... My vote would be not to duplicate items in the nav

Shawn: We could have the sub-pages link to the other pages, though

<shawn> https://w3c.github.io/wai-website-components/components/preview/example-home-alt3

Example of duplicate discussed: Before and after demo (BAD)

Brent: Is BAD going to be it's own design and have it's own breadcrumb trail?

Shawn: That's one we probably won't have the main nav on top due to how it's made

Vivienne: It's important to have things only in one place. Easier for folks and also search.

<shawn> Robert: echo not in 2 places. 1 place fine. open to either place for BAD. can link to it from sub-pages.

<Zakim> yatil, you wanted to say breadcrumb/microsite header

<Zakim> yatil, you wanted to say t&a

Eric: Likes the consensus of having it in only one place, and agree with Vivienne that it should be in Teach & Advocate section.

<Laura> +1 to eric's idea about BAD being in Teach & Advocate and having a minimal header

Brent: Concerned about having it in two places in the nav - especially with confusion around breadcrumbs

<Vivienne> +1

Proposed resolution: Keep items to only one location in the nav

<shawn> +1

<Laura> +1

<Brent> +1

+1

<yatil> +1

RESOLUTION: Keep items to only one location in the nav

Proposed resolution: BAD belongs in Teach & Advocate

<Brent> +1

<shawn> +1

<Laura> +1

+1

<yatil> +1

<Vivienne> +1

RESOLUTION: BAD belongs in Teach & Advocate

<shawn> Essential Components/[How Accessibility Works] in both Accessibility Fundamentals and Standards/Guidelines ?

<shawn> https://www.w3.org/WAI/intro/components.php

Brent: I'd look for this under Fundamentals rather than Standards/Guidelines

<Vivienne> I'd look in Accessibility Fundamentals also

<Brent> +1 to Eric

<Laura> +1 to eric

Eric: We have a lot of resources that sound the same, so I think we should be clear about what a resource is. Essential Components might be better named as How the Standards Work Together

<Brent> I like the name idea Eric has about "How Standards work together"

Eric: I feel this should be in the Standards & Guidelines section because the intent is to show how the W3C standards are designed to work together.

<shawn> https://github.com/w3c/wai-components/issues/1

Group - review the email thread and minutes where we talked about ideas for naming this resource

<shawn> [discussion of approaches for where this fits...]

<Brent> Robert: I see Eric

<Brent> Robert: I see Eric's perspective under standards and guidelines.

<Zakim> yatil, you wanted to say we need a What W3C standards are there overview page, I think.

<Laura> +1 to Shawn

Proposed resolution: The Essential Components document lives under Standards & Guidelines but is linked to from other pages/sections wherever appropriate or helpful

<shawn> +1

<Brent> +1

+1

<Laura> +1

<yatil> +1

<Vivienne> +1

RESOLUTION: The Essential Components document lives under Standards & Guidelines but is linked to from other pages/sections wherever appropriate or helpful, specifically the Introduction section

Group considering renaming the resource to make it more distinct and appropriate

<shawn> https://github.com/w3c/wai-components/issues/1 How Standards Work Together

<Laura> +1 to Brent and Eric. How standards work together

<Zakim> yatil, you wanted to make my point from earlier which is more related

Brent: "How Standards Work Together" feels more focused than "How Accessibility Works" which is too broad a topic

Eric: This page could be a good overview for the different standards to answer questions. Perhaps this page could be titled "Accessibility Standards Overview"

Shawn: I'd like to take a pass at making this page do both jobs

<Vivienne> I like the idea of 'how standards work together'

General agreement to explore revising the working title "How Standards Work Together" and make the content reflect that more accurately

<shawn> Business Case in both Plan & Manage and Train & Advocate?

Proposed resolution: Keep Business Case in Plan & Manage in the nav and link to it from other sections

<Vivienne> I'm fine with that Shawn

<Laura> +1

<yatil> +1 [Eric envisions a page “how to convince/advocate in businesses” in the future]

+1

<shawn> +1

<Brent> +1

RESOLUTION: Keep Business Case in Plan & Manage in the nav and link to it from other sections

<Vivienne> +1

Category Headings in Navigation

<shawn> category headings in nav (How People with Disabilities Use the Web, Planning and Managing, Developers's Intros, Tutorials, Eval Tools, Conformance Eval) — to link or not to link? Some people didn't want any "annotated nav pages"; however, I'm thinking that we'll need them for some of the pages where the old URIs were very popular: including How People with Disabilities Use the Web, Tutorials,

<shawn> Getting Started Tips, possibly Planning and Managing.

<shawn> https://www.w3.org/WAI/intro/people-use-web/ landing page

<shawn> https://www.w3.org/WAI/impl/Overview landing page

Shawn: One of the issues with these pages is that the resource or material is very old. We may still need to have a page called "How People with Disabilities Use the Web" but not have it clickable in the nav

Laura: What we do when people say "we know that, we've bookmarked it, etc." we still redirect them to the new content after the pages/structure has changed

Vivienne: In the mock-up under fundamentals, are you saying the item in the main nav will not be clickable but the children of that page/section will be?

Shawn: We could choose to make the items clickable or not.

Vivienne: Want to ensure we are consistent about what is clickable and not in the nav in order to reduce confusion

Shawn: We will likely want to send this to Charlotte for usability testing

Brent: I like to have some sort of overview page with a level-setting paragraph to understand what is being shown to me

<yatil> Tutorials Overview page, Brent: https://www.w3.org/WAI/tutorials/

Brent: To me it doesn't matter if a link isn't clickable when it has submenu items

<shawn> s/I've lost audio, is it just me?/ /

Eric: For me, not linking a navigation element is an anti-pattern
... Not linking the items is problematic in terms of expected interactions/keyboard navigation/accessibility
... I prefer having overview pages for everything

<shawn> Laura: be consistent

<Brent> +1 to consistancy

<shawn> +1

<shawn> Robert: subsection of Plan & Manage & subpage of PLanning and Managing

<shawn> Shawn: yeah, raised that as an issue and didn't get any reply :(

<shawn> Robert: ... coming around to having them linked.

<shawn> .... a little content writing to make them useful

Vivienne: I'm in favor of having a landing page for the accessibility of it — allowing people to get a good overview of the resources available.

<Brent> +100 to vivienne

<yatil> +💯

Vivienne: Links to all the relevant material on one landing page would be helpful
... ... to point people to

<shawn> +1

<Laura> +1

Vivienne: This is especially important for people with cognitive issues — having a single page with all the resources linked will make it more valuable and easier

<yatil> Tutorials Overview page, Brent: https://www.w3.org/WAI/tutorials/

<Zakim> yatil, you wanted to say when we don’t need an overview page, we don’t need another step in the navigation (bit devil-advocating here :-D)

Brent: Will this mean we need to have landing pages for all of the subsections within the navigation?

<Brent> I like what Vivienne is saying, include simplistic landing pages and link to the landing page as well as subpages.

Eric: If we don't want to have an overview page, we should consider making the subpages part of the main hierarchy

<shawn> https://www.w3.org/WAI/eval/Overview

<shawn> ack

<Zakim> yatil, you wanted to say we can have unlinked headings like in the alternative option and to point to https://visa.invisionapp.com/share/RUCY9YUQE#/223719150_Menu_-_Expanded

Proposed resolution: Every menu item is linked, and there are landing pages for those items that have subpages

<Brent> +1

+1

<yatil> +100%

<Laura> +1

<shawn> +1

<Vivienne> +1

RESOLUTION: Every menu item is linked, and there are landing pages for those items that have subpages

<Laura> Vivienne'ss comment convinced me too

<Brent> What really swayed me in this direction is Vivienne's comment that it is very useful to have an overview page to send people to when sharing a resource with others. If you don't have an overview page, then you have to send them to a subsection of the resource which is not always the best thing to do.

Shortened Names for Nav

<shawn> https://docs.google.com/spreadsheets/d/1pqcSChcWZwTShpov34jDfvX2E-jW6_M5khV38D53Qqk/edit#gid=887243996

<shawn> examples:

<shawn> full title: How to Make Your Presentations Accessible to All

<shawn> nav:

<shawn> Make Presentations Accessible

<shawn> full title: Developing Accessibility Presentations & Training

<shawn> nav: Develop Accessibility Training

Vivienne: I'm wondering what happens when you're searching for things if the titles are shortened too much
... This could introduce a consistency issue

<Brent> Vivienne: People may be confused because the title is slightly different and think that they got to the wrong page.

Laura: Shorter titles are always better, and we should not keep a long title in the nav just for historical (because it's always been that way) purposes

Eric: The challenge is we have very long titles for our resources, often repeating words in larger categories
... There are redundant terms like "Accessibility" which we could lose

Planning & Managing

Shawn: Where are people on the question of whether or not the duplication is a problem?

Laura: I think it's a problem and we should address it.

<shawn> redundancy between Plan & Manage menu heading, and Planning and Managing resource

Laura: With Plan & Manage being the main category, and Planning & Managing Accessibility as a subtopic, we should rename it to something more specific

<shawn> [ Shawn notes we had similar issues with current nav and resources ]

Brent: All of the resources in the submenu fall under "Planning & Managing..."
... ... so I'm OK with it.

<yatil> [ Thinks breadcrumb: Home -> Plan & Manage -> Planning & Managing Accessibility -> Initiate ]

<shawn> Robert: Plannnng & Managing is the doing of it

<shawn> ... maybe program management

Shawn: I propose we open an issue on this to see if someone comes up with good ideas on this.

<yatil> [ Thinks breadcrumb: Home -> Plan & Manage -> Start with you Accessibility Plan ]

Shawn: We also add this for something to watch for in usability testing

<shawn> Robert: big fan of usability testing to see if people have problems, if not, they fine

<Laura> +1

<yatil> [ I think the inclusion of Accessibility in “Planning and Managing Accessibility” makes the difference here. ]

<Brent> I worry that if we change the name of the resource we will lose the quick recognition of what the resource is about.

Shawn: I'm happy to leave it as-is unless it poses a problem for users.

General agreement on that

<Brent> +1 to open an issue.

<shawn> scribe: shawn

trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Meeting number: 312 375 338/ /
Succeeded: s/I've lost audio, is it just me?//
FAILED: s/I've lost audio, is it just me?/ /
Succeeded: s/Viviens'/Vivienne's/
Succeeded: s/exa,m[ples:/examples:/
Succeeded: s/problem/challenge/
Default Present: Laura, Sharron, Brent, Eric, Shawn, Robert, Vivienne, 💯
Present: Laura Sharron Brent Eric Shawn Robert Vivienne
Found Scribe: Robert
Found ScribeNick: rjolly
Found Scribe: shawn
Inferring ScribeNick: shawn
Scribes: Robert, shawn
ScribeNicks: rjolly, shawn
Found Date: 25 Aug 2017
Guessing minutes URL: http://www.w3.org/2017/08/25-eo-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.