Upcoming usability study

Brent: Usability study provided by Visa tema in Austin. Since one of our goals is to make things easier to use, we want to see how the navigation and other leements of IA into a final shape to is used.
... since many of our names are long, not intuitive, contents may be a bit changed through revisions, some renaming is needed.
... thanks to Shawn for all the hard she did in putting this together. Trying to get naming feedback. We have gotten some on the surveys but many have been opened on GitHub with out anyone knowing. This can be tedious and we appraeciate your putting on your naming hat today to help that.
... willinvite Shawn to walk us through the process. There is some info in the GitHub, will provide time to read the issues and then will moderate suggestions and brainstorming.

Shawn: Also want to introduce a new WAI staffer, can he introduce himself?

Roy: I am from China - Ruoxi Ran. I have a Mastersin software engineering, focused research in accessibility, and recently joined WAI. Am happy to join and will try my best to do this work well.

Shawn: We are very excited to have Roy help get contributions to our work more widely from around the world.
... thank you.
... goal today is to not necessarily get to final titles on each of these but to get shared understanding. For context, see prototype navigation with shortened titles; full titles are in Proposed navigation (Google Sheet).

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

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

Shawn: hopefully you have looked at the navigation prototypes and today we will look at full name and short names that will be used in the nav.

Naming of Essential Components of Web Accessibility

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

Shawn: one of the goals of this is to show how different standards work together, highlight that there are reponsibilities within different roles, and talk a bit as well about the user perspective.

<shawn> (in Nav under "Standards/Guidelines" as placeholder

<shawn> "[How Standards Work Together]")

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

Shawn: placeholder is within Standards/Guidelines section and currently is "How Standards Work Together." There is a GitHub issue about the naming.

Denis: Quick question, should we open new GitHub issues if we wish to comment?

Shawn: Yes you can do that and it will be important to indicate if you think it should be done before or after launch and make sure as well that the RM knows it is posted.

Shadi: Do you want discussion now or do you want us to only put things in GitHub.

Shawn: Don't have to do both, can talk now and we can link to minutes, so jump in with questions, comments, first reactions.

<shadi> [[bird's eye view on web accessibility | making the web accessible | the grand scheme]]

Sharron: I like direction of How Standards Work Together... but it sounds like maybe there is more in there. Title may therefore need to be broader like How Accessibility Works... What Makes Accessibility Work

Shadi: I don't think it is only about standards and we don't necessarily want it to be. It is really talking about how it all fits together, would be good to give that picture.

<shawn> [[ ...fits together..]]

Sharron: Do we want to change the picture too?

Shawn: Yes it would be great to have it updated

Eric: If it is about more than Standards, maybe it needs to go in Fundamentals instead - otherwise the focus should remain on Standards. And recall that Alicia is working on updates to graphics.

<rjolly> wonders if it's better named as the Accessibility Ecosystem after hearing discussion

<shadi> +1 to Eric - may indeed be more spec-focused

<yatil> Likes the name Accessibility Ecosystem

Shawn: There was some discussion about leaving it here, saying more about the Standards including WAI ARIA and overlaps

Shadi: Now am looking at the fact that the Intro has some good material already. Since this is an intro with Standards section, it may need to have more of a focus on the standards and how the standards fit into the ecosystem.

Shawn: There is no other intro in the Standards section, so that may have an impact on content. Not to take out the other stuff which is informative and not covered anywhere. It will bring in ARIA (not there now) and the focus is to be how the standards fit in the great scheme of accessibility.

<Howard> I concur with putting it under fundamentals

Brent: I am going to jump in without my chair hat...I don't like How Accessibility Works since it seems too broad. "How Standards Work Together" seems more accurate and more focused on what the content actually is and ties it all together.

Norah: I agree that if the Intro paragraph to focus more on the topic of How Standards work together, the purpose will be clear and that will be a good title.

Shawn: I will take a pass at making that edit and then will ask for GitHUb comments.

Naming for The Business Case

<shawn> https://www.w3.org/WAI/bcase/

<shawn> https://github.com/w3c/wai-bcase/issues/3

Shawn: Editors want to take a new approach to the Business Case to reduce to just one page and link to more developed case studies. Current title is Developing the Business Case for Your Organization. Will have discussion and continue it within the GitHub. We did have a lot of discussion years ago and may want to look at that and think about it.

Denis: More about what those changes will do?

Shawn: Later in the call we will do that
... suggested rename is simply "The Business Case for Accessibility>"

Brent: Is the term Business Case globally recognized? Does it have the same meaning all over the world?

<yatil> [ OK from German perspective, I think. ]

Shawn: Will ask those with international perspective to weigh in either now or in GitHub
... it is an important question.

<yatil> [ In German it is "Business Case". We lend all the words.]

Denis: Don't know that we have a direct translation in French, will think more about that. Business case translation - I think the closest in french for FR-fr peeps would be "argument commercial", but here in FR-ca, it's probably more like "?tude de cas" (which literally translates to case study)

Naming of Easy Checks

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

<shawn> https://github.com/w3c/EasyChecks/issues/84

Shawn: For Easy Checks, want people to skim through what is in the GitHub and consider that as part of our discussion today.

<Howard> I don't see a compelling rationale for changing the title

Howard: See no compelling reason to change the title. The points about the current title, like it's not really that easy is OK but does not balance against the name recognition this has gained. Quick Checks does not imply this is preliminary, a first check. See nothing that improves it enough to justify a change.

<shawn> [ agree, we already ruled out "quick" ]

<shadi> [[smoke test | rough check | coarse review]]

Brent: I know that when Caleb worked on it he said it was misleading - it is not really that easy. What part of it is hard? It is not about fixing but only to identify issues.

Denis:I have always thought "Star Wars" was not a really good name, but everybody refers to them by that name now, so it's too late to change it. I feel the same way about Easy checks.

Brent: is the "not easy" part meant for the checking or the fixing?

Norah: I agree and even though making the changes may not be easy, this resource implies this is an "easy" way to get started, by focusing on the issues on this page

Shawn: Particularly the forms section is not that easy. But most of it is fairly easy. However I will say that in live trainings, non-tech people have more trouble than we expected.
... often the questions are beyond the simplicity of the check and have to do with how to fix so that is a good point.

Robert:current title works well for me. people will arrive because of "easy" and it is accurate about the "checking" as Brent and others said.

Brent: Most of these can be performed within 15 or 20 minutes so I think Easy is an OK title.

<shawn> [ Shawn thinks 5 minutes once you've done it several times]

Norah: I have used and shared the resource, the name implies correctly that it is an easy way to get started in identifying errors/barriers.

<Sylvie> +1 to Norah and keeping the title as is.

<yatil> [ OK with easy checks. I think we could make many of them even easier. ]

Shawn: The idea has come up a few times about "common Problems" being something that people would come to the site for and could not find in our exisiting navigation.

<shawn> Easy Checks for Some Common Web Accessibility [Errors|Bugs|Problems|Barriers]

<Brent> +1

<Norah> like it

Shawn: so a suggeston has been to add "common problems" to the second part of the name.

<Howard> I like the current name. Don't like the proposed alternative

<Laura> +1

<j-pulido> I like it as is

<rjolly> 50/50 about that name. not much better than the current title. definitely not bad, either

<yatil> =/- 0

<dboudreau> +/-0

<yatil> -.05

Sharron Like the phrase "Common Problems". reasons for doing that resonate. word "some" bothers me. it's clunky

<dboudreau> To me, Easy checks refers to either low hanging fruits or biggest bang for your buck

<shawn> ... not sure about it. I could go with it.

Brent: I like solving common problems because you do get a sense as you use it that these are common problems

Sharron: it is the word "some" that makes the title clunk. Not string feeling, just annoying

<Norah> could focus on common problems in the introductory paragraph rather than the title

<Brent> +1 to Norah

Howard: Yes but it needs to indicate this is a first review, it is not comprehensive. I would keep the current title since there is not one to the suggested change.

Shadi: Easy, simple, those kind of attributes are highly subjective. Something like first reveiw, rough review, something that is less subjective.

Shawn: And what is your thought about abondoning the well known, established Easy Checks?

Shadi: Is it that well established?

Shawn: yes

Eric: If we say common problems, don't need to use "some"
... could be "Easy Checks for Common Problems" or something like that. Agree with Shadi that Easy is subjective. I think most of the checks are really not that easy especially if you have no technical background. It is a well known name.

<shawn> ... Web Accessibility [Errors|Bugs|Problems|Barriers]

<Howard> -1

Shawn: Can I get quick reactions to the suggestions for "Errors" or "Bugs" or "Problems" or "Barriers?

Howard: I think the title is good, would not see the name for all those terms.

<Norah> I prefer common problems

Shawn: No sorry, wanted to think about choosing just one.

<Norah> Common problems in the intro paragraph, keep same title

Howard: Don't see that it adds that much. If I had to, might change to "Easy Checks: a first review of accessiiblity problems"

Denis: Never thought Easy Checks was the best name but based on what you said, if it gets traction I would hesitate to change them. The words suggested all have problems. One that is commonly used is Failure which I would warn against but one that is commonly used is "Issues" which seems widely used and more neutral.

<Norah> users may be looking for "How to get Started"

Shawn: Current title doesn't necessarily help people find it. One of the goals is to make resources easy to find and there is a feeling that in this case, the name doesn't help.

James: Findability is one of the main problems we are trying to solve in the redesign. If we improve the findability of the site and also specific resources within the site, we could attract a much wider audience. If people actually find what they are looking for, they could increase traffic ten fold easily. These are not people who will ahve previous identification with Easy Checks. If we agree that the current one is not an aprropriate title and is more accuratly called an intro to evaluation should accept that and understand it may need to go in that section.
... don't use inaccurate titles, name it more accurately, and help people find what they are looking for. Will get more traffic as we have more satisfied users.

<Norah> good point, First Checks: How to Get Started

<Roy> basic accessibility check

<rjolly> I like Roy's suggestion for Basic Accessibility Checks

<shawn> Roy: common = basic in China

<rjolly> very straightforward

Roy: In China when you define common problems as basic problems. In that case the title may be something like that.

Denis: Is the forms section really basic?

<yatil> +.2 to basic accessibility checks

<yatil> [ Checks for basic accessibility issues ]

Sharron: I think the point here was to try to assure people that you don't have to be an "evaluator" you don't have to be particularly technically savvy beyond basic user interface understanding - what an image is, what forms are meant to do and other interactions, etc. Instead, it's a way for anyone to check very basic stuff.

Brent:"Basic" does not mean "Easy." Basic means forming an essential foundation or starting point; fundamental.

Sharron:"Intro to Evaluation" is not quite right either, since someone may use this and never go on to do more detailed evals. And I beleive it is often used this way. We often recommend to K-12 schools and teachers looking for classroom software. Do these Easy Chacks before you buy.

<dboudreau> how about - Easy checks: accessibility evaluation low-hanging fruits?

<Norah> First Checks: How to Identify Common Accessibility Problems

Denis: Low-hanging fruit?
... Bang for your buck?

<dboudreau> +1 to Robert

<shawn> First Pass

Robert: It is likely that at some pont we have to admit that some of it is complicated and that's ok. expecting that we can pull someone off the street and do all of these checks is probably unrealistic.

James: My thought is something along the lines of "Beginning" and first pass

<shawn> Beginning

<shadi> +1 to james

<Norah> How to Get Started

<Howard> If you're going to make a change, I like Norah's.

<shawn> [ I wonder if "Getting Started" sounds like they'll do more -- different from what Sharron said of some target audiences ?]

Robert: I am OK with changing it from Easy Checks to Basic or First or Getting Started it is OK. But we have to recongize that it may take some kind of experience to do a few checks at any level. We can try to make it as simple as possible. My mom for example would not be able to follow this - and that's OK

Eric: I am along the same lines as what Robert said. If we keep Easy Checks for now maybe we can introduce more complex levels of Checks to expand the resource in the future and that would be useful. A large undertaking but could then steer people to the level of eval they are going for.

Shawn: In our charter is a complete revamp of Easy Checks... but after launch

James: Maybe having the same level of tutorials for evaluators with a specific section for each element being tested.

<Brent> +1 to future evaluator tutorials

<Laura> +1 to James comments

<yatil> +1 to James comments

<Roy> +1 to James comments

Shadi: Absolutely agree! And James there is ongoing work in Conformance Testing that you and others at Visa are welcome to join.

Naming for How PWDUW

<shawn> https://github.com/w3c/wai-people-use-web/issues/49

Shawn: Current resource has 4 pages, current plan puts landing page up one level and addresses confusion between Diversity of Web Users and Diversity of Web Use. There are minutes about how these names were chosen.

<shawn> [ Shawn put those placeholders, but did not think a lot about them]

<shawn> Diversity of Web Users (in Nav under "Accessibility Fundamentals" as placeholder

<shawn> "[Diverse Abilities and Disabilities]")

<shawn> Diversity of Web Use (in Nav under "Accessibility Fundamentals" as placeholder

<shawn> "[Tools and Techniques People Use]")

Norah: Currently we have placeholder titles that will be a start. The two titles are so similar it is easy to get confused between them. I will spend some time thinking about them. The placeholders are Diverse Abilities and Disabilities and the other suggestion is Tools and Techniques People Use
... these are in the GitHub

Sharron: I like Diverse Abilities, but it is in "How People with Disabilities..." so why add Disabilities?

Norah: Not sure where they came from, I like that point.

Shawn: Thsoe were not even real suggestions just a way to indicate two very different titles.

<shawn> +1 to Sharron's point -- good to consider

<Norah> Diverse Abilities and Possible Barriers

<shawn> ... especially since under "How People With Disabilities Use the Web"

Shawn: It is under the subcategory of How People with Disabilities use the Web

<shadi> [[Diverse Abilities | Tools and Techniques]]

<shawn> This page explores the wide range of diversity of people and abilities and highlights some of the types of web accessibility barriers that people commonly encounter due to inaccessible designs of websites and web tools.

<yatil> +1 to Diverse Abilities, Tools and Techniques

+1

<Brent> +1 to Shadi's suggestions

<Norah> +1 Diverse Abilities, Tools and Techniques

<shawn> Diverse Abilities and Common Barriers

Shadi: Since it is a sub page, longer title not needed

Brent: I like the simpliefied versionas well

<Sharron>+1

Naming of FAQ pages

Shawn: There are three pages created to address specific narrow issues. One is explaining why standards harmonization is essential; one is relationship betwee usability, accessibility, and inlcudsion; one is does W3C have mobile accessibiltiy standards?
... the idea came up a few years ago the idea to have pages to address specific issues. A suggestion was raised to have focused FAQ pages to address those question, not change the content, just change the title to reflect the focus.

Denis: Your explanation makes sense, but seeing it mocked up, I don't like it.

Sharron: What about it don't you like?

Denis: It seems as thought we have built this navigation but we ran out of ways to organize materials and so stuck it there since we had no other place to put it.

Denis: would rather have a section called FAQs and put them there together.

<shawn> +1 to Brent "FAQ" usually different

<Norah> could it be a glossary?

Brent: I had a similar reation to Denis. Although you explained it well, I worry about using FAQ in a way that will surprise people. The FAQ is generally site wide and may have questions about different topic and organziaed that way and most often reply to questions that have been asked within the community. Any deviance from that standad was of using it, seems odd and will likely confuse people.

<yatil> +1 to dboudreau

<Norah> can you put in a link to current page?

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

<Laura> +1 Brent's comments

<shawn> https://www.w3.org/WAI/Policy/harmon

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

<shawn> https://www.w3.org/WAI/mobile/

Eric: Seems odd to have an FAQ about just one topic but think of it more like a Fact Sheet, the collected information about that topic. It makes more sense to collect disjointed info distributed through out our resources into an information page or fact sheet.

Sharron:yes, I kind of like "Fact Sheet,"eems appropriate.

<Brent> +1 to Fact Sheet

<shawn> Thanks for brainstorm ( might get pushback for A, U, I)

<shawn> White Paper

<Brent> Brief

<rjolly> -1 for Brief and White Paper

<Norah> "at a glance"

<Sharron> +1 for at a glance

Mobile Accessibility pages

<shawn> Mobile Accessibility Standards FAQ page and new resource

<yatil> [ +1 to at a glance ]

Shawn: Current page people come to to see if W3C has mobile accessiiblity standards. The answer we provide is - here is what goes on around mobile at W3C. Answers specific question.

<scribe> ...new resource is Developer's Intro to Mobile. EO editors noticed that the intro is of much broader content than just for developers. Need to think about that and how it all fits together. Related to that is the new WAI-ARIA resource, should they both just be an "intro to..." or do we want to keep titles as is and foucus content.

Sharron: If the rest of the the content is in fact developer focused, is there an option to move the intro?

<shawn> [ Shawn notes "At a Glance" is used for https://www.w3.org/WAI/WCAG20/glance/ and https://www.w3.org/WAI/intro/atag-glance]

Shawn: Could make two separate sections or separate resources -- one for general audience and one for developers

Presentations You Can Use

Shawn: Trying to get a clear titles, will open a GitHub and invite your thouthts.

Interim Repair

Shawn: PLanning team needs to discuss whetehr the issues raised on this one whould be addressed before or after launch...and then will bring to all of EOWG

Brent: Thank you Shawn

Business Case

Brent: Proposal is currently to reduce the resource drastically and to take a new approach.

<shawn> old/current page -- https://www.w3.org/WAI/bcase/Overview

<scribe> Scribe: Brent

<shawn> Suggested editing approach to Biz Case https://www.w3.org/WAI/EO/wiki/Business_Case

Sharron: On agenda for us to start thinking about. This was developed about 10 years ago or more. At the time, the idea of having a Business Case was very important as many organizations did not give importance to it. My own experience seems to indicate that now the Business Case is much more at the top of people's minds, most people know it is an impotant consideration and don't need as much persuasion. In the US, the ADA and DoJ directives have drivien much of that.

<yatil> [ Wished we had that in ???? ]

Sharron: Editors feel like we do not have to dig as deep in this resource any more. The concept and importance of this can by expressed with much less content in the resource.
... But we would like to know more about the perspective of the global community outside of the United States.
... It is important that we be very modern in how we talk about this. Asking businesses if they have a policy, something around diversity and inclusion that can help drive an accessibility initiative
... We want to know if this type of tersification is a good approach and if we should move forward with it.

Denis: I used the resource for many years and have fairly recently stopped using it. I began to hear dismissive comments indicating that the document because it did not age well.
... I could find some of the blog posts dismissing the value of it. Coming up with a shorter version is a good idea and maybe recognizing the value tht is still there to put into a different document.
... a way to debunk a lot of the reasons people do not do accessibility are addressed here. A document that prints into dozens of pages however will not be read by executives and those who make the decisons. Still many of the points are still valid and should be retained somewhere.

Shadi: I think this and the HPWDUW were made to justify the guidelines. Good to remember that many countries do not have anti-discrimination law and need deeper justification.
... a new approach and tone could go a long way to doing that.

<James> +100 to shorter documents!

Denis: This may be an unpopular view and I apoligize if so, we will benefit from creating shorter, easier to read documents overall. Things that are less dense. If we try to create shorter documents that are more to the point, it will help to reach more people. One of the reasons I stopped using the Business case was that I kept being told that "no one will read this, please summarize." As we try to be so precise, we make longer, dense documents that are not used or read.

Shadi: Wait until you see the good work Norah is doing around HPWDUW. She has made shorter, readable docs.

Brent: Same experince at Pearson. People want summaries

Eric: Agree that shorter docs are needed. Also consider needs of the demographic that needs the deeper numbers and facts.

<dboudreau> +1 to Eric, yeah... but maybe as some kind of a handout to download with the actual resource that's shorter and more to the point

<shawn> https://www.w3.org/International/questions/qa-escapes

<shadi> +1 to summaries/abstracts

<yatil> +1 to summary + backgrounder

<Brent> Great idea for lengthier resources, having a quick summary at top.

Shawn: Have considered creating summaries to some of the resources and link to longer version with greater detail and to specifics that may apply to only limited cases.

<shawn> https://www.w3.org/WAI/users/inaccessible

Sharron: I think this is a splendid idea!! A big part of our redesign goal is to make living, relevant documents that are an essential part of the global tech landscape and that continue to change and evolve along with it. case studies that really illustrate the broader benefits of accessibility inlcuding responsive, flexibility, solving unanticipated problems. Making the point that accessibility is just good business.

<dboudreau> Where are the ESPN and Legal & General examples of today to support standards and accessibility?

<yatil> +1 to what sharron is saying!

<dboudreau> "Yuuuuuuuge" +1 to what Sharron just said. :)

Wrap up

Brent: I am wearing my PM hat quite a bit these days, managing all of the projects you are working on. Please do stay in touch. Will start posting naming issues and try to work within surveys to get to solutions. As always thank so much for your good work and ideas. Watch the work fo this week and look for a survey. Any other business?