Introductions

<Vivienne> Andrew Arch sends apologies as he is away on holiday

Brent: Several are attending for the first time and welcome to Amanda who joined us at TPAC but not been attending meetings. Quick round to say who you are, where you are, what you do

<shawn> refresh agenda at January Teleconference Agenda

IRC commands and other tools

<shawn> EOWG_Participation_Info

<shawn> To type something that you do not want recorded in the minutes, preface it with:

<shawn> For example:

<shawn> It will show up in IRC with an asterisk and will not be in the minutes:

<shawn> * shawn apologizes for the construction noise in the background

Brent: Everything typed in IRC is minuted. Side comments can be made using /me
... also we use a queue, as you want to comment or ask question, use q+ to get on queue

<shawn> "q+ to say I Prefer option 2"

<Zakim> shawn, you wanted to say I Prefer option 2

Brent: If you say q+ to say "something," zakim will remind you what you wanted to say

<Chris> I think query is right, Howard

Sharron: When you join on IRC, use present+ 'your name' to record that in the roll. Use the wiki page to keep up with current work , link to surveys and suggest items for next agenda.

<Sharron> EOWG Meetings page in wiki

Revision to Intro to Accessibility

Brent: Shawn has done considerable work over an expended time on these resource, addressed GitHub issues, etc. We are trying to get many resources in shape for new site.

Shawn: This is a new process and will provide some reading time today but normally we do *not* do that. Appreciate when people can read before hand. There have been comments within the GitHub in the last hour, not sure I am caught up.

Simple definition, git hub issue #3

<shawn> Intro-accessibility issue #3

<shawn> proposal: "Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them."

Shawn: Take a minute to get acquainted with the issue and what may have happened since you last looked.

Sharron: Leaning in the right direction, I like your 2nd version

<Chris> +1

<AMace> +1

<Laura> +1

<Brent> +1 with last option

<MattPutland> +1

<rjolly> +1

<Howard> +1 last option

<yatil> ok

RESOLUTION: Accept the wording "Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically,..." in the Intro

Links to more info

<shawn> Intro-accessibility issue #5

Amanda: Keyboard users would be able to use the expand function, seems to clean up clutter from a page although I tend to open them anyway.

Shawn: We can also have an option to have them expanded by default with an option to hide them

Sharron: If expanded by default, it makes me wonder why put the option is there in the first place.

<MattPutland> +1 Sharron

<yatil> +1 Sharron

Robert: I really feel like we can easily go one way or another and change it later if users react badly. I think option #2 is the best, easy to skim, can grab if I want it but easy to ignore. Feel like it is a toss up however. I have a preference, but not a strong one, not critical. No need to get too hung up on it.

<Chris> +1

<MattPutland> +1 Robert

Howard: I agree. I like the boxes, people may miss it if it is hidden in an expand function. But if expanded by default it is the worst of both worlds. The indented boxes make it easy to find, also easy to skip past

<Laura> leaning toward alt 2 also

<AMace> I don't feel really strongly one way or the other

Shawn: Without editor hat, mildly prefer expand if buttons are quieter but happy to go with indented boxes.

<shawn> indented: Intro-accessibility links-alt2

<yatil> +1 to no expand collapse

<shawn> not indented: Intro-accessibility links-alt4

Norah: Another issue with the expand function, when you return to the site it is hard to find the materials that you "know" you saw on the page but don't want to open each one.

Shawn: There were two versions of the indent boxes, one was not.

<Chris> The non-indented one, ALT 4, is my fave, but am fine with way

<Howard> Indented is easier to distinguish visually

<rjolly> I like indented version - makes it more obvious that it is related to the parent section

<Norah> +1 indent not needed

<Vivienne> I think I'd prefer not indented

<Laura> +1

<Chris> +1

Shawn: Thought the indented one would be easier to skim but now feel like they add visual confusion. Propose we go with alt 4, not indented.

<AMace> I prefer the not indented

Matt: People mention clutter and the indented version definitely pulled my eye in that direction.

Eric: Boxes make it clear what is extra, no need for indent. The indentation adds clutter and also draws focus to the boxes instead of away from it

<Chris> Good point, Eric

Eric: might also be harder to be successfully responsive.

Robert: Indent for me clearly associates the content with the previous content rather than what follows. That is not as clear when the boxes are not indented.

<Brent> +1 to Roberts association comment. That is why I liked the indentation too. But okay with group decision.

Eric: We already have seen through testing that we need more space between h2s and that may help with the content association.

Robert: Think you are right, a bit more white space would help me.

<yatil> +1 to More info on "Section Name"

<yatil> (Also good for screen reader header navigation)

Shawn: Could (just a brainstorm) could add 'More info on "specific topic"' worth it?

<Chris> +1

Vivienne: I think it would be nice for the screen reader user if it says More info on...otherwise may have issues repetitive More info.

<Chris> I had the same thought last night

<AMace> +1 to Vivienne's comment

<Laura> +1

Matt: The more info is marked up as a header, not a heading, may want to make it an actual heading so navigating with H would not find it.

Eric: Yes would likely make it an h3 or h4

Shawn: Proposal is to go with More info boxes, no expand, left aligned, not indented; More info on blah blah blah (may shorten somewhat) and add more space above h2

Norah: One section where More Info box contains more content than the paragraph. Unbalanced, so paragraph no longer feels like central information.

Shawn: That version had been revised, two sentences, and big more info and so they were all put into one box, no longer an issue.

Norah: As I look at it, it seems the bulk of the content is in the More Info box in alt 4

Shawn: Please do put in GitHUb as a new issue
... any other comments?

RESOLUTION: More info in boxes, no expand; left aligned, not indented; More info on blah blah blah (may shorten somewhat) and add more white space above h2

Benefits to others github#8

<shawn> https://w3c.github.io/wai-intro-accessibility/fundamentals/accessibility-intro/#what

<shawn> Any strong opinions on GitHub 8?

<shawn> "Web accessibility also benefits people without disabilities, for example:..." vs

<shawn> "Web accessibility also benefits other people, for example:..."

Shawn: Somewhat at the level of wordsmithing, want to avoid getting in the weeds. Let's try to do that.

<shawn> https://github.com/w3c/wai-intro-accessibility/issues/8#issuecomment-358702287

Shawn: strong feeling for either of those options?

<Norah> prefer without disabilities, rather than other

<AMace> prefer withour disabilities

<Laura> +1 to Norah

<MattPutland> I think without is a bit more clear

<Brent> okay with either

<Howard> prefer without

GitHub #12

<shawn> https://github.com/w3c/wai-intro-accessibility/issues/12

<Laura> done

<Vivienne> done

Sharron: done

<Chris> done

<Howard> don't like "with limitations" - unclear

<Norah> agree, don't like "with limitations"

Sharron: Not convinced that there is no "reason" in the current statement. It is implied rather than stated entirely but t seems quite clear to me. Since we are strongly commited to brevity and tersification, having an implied reason as long as the implication is clear - and it is here - it seems good.

<Howard> +1 to Sharron - implied is fine

Vivienne:Could we somehow introduce the idea of situational access? And I am not fond of "with limitations" For consistency it may be needed, but I don't like that phrase

Shawn: Given context, would people be comfortable leaving as is?

Norah: I do feel that it needs clarification, something that identifies the need, and something other than limitations. I think it will be helpful, will faciliate people understanding the point if they have more of an identification with the issue

Shawn: Just a reminder that there is a link that explains the detail. The point here is just to say 'hey there are additional benefits'

Vivienne: Situational access issues may help make that point without taking a lot of room.

<Norah> +1 to Vivienne

<Chris> device agnostic

Shawn: We have a reference to situational, (reading) "people in an environment where they cannot listen to audio."
...the original intent is to remind that there are reasons beyond disability and point to detail if needed.

Brent: Where did we land on switching the order? Since the others have issues included, maybe putting this one last would make it less stand out.

<Norah> +1 I thought order should be changed as well

Shawn: The idea was that mobile would grab a lot of developers and designers. Would resonate with more people and draw them in.
... we focus on disabilities and also want to grab those who may be willing to ignore that audience by giving them other benefits.

Amanda: Having mobile devices and smart TVs as the lead is a good idea. Device flexibility may be a way to talk about this.
... I really like Eric's point to separate out the two types and remember that unless you are in the world of a11y, may need reasons.

Howard: Not convinced that anything needs to be added but if so, could say mobile phones, smart watches and other small screens.

Norah: Going back to the fact that since this is for people new to the topic, it may be necessary to have device dependent reference, a bit more about situational limitations. Had to follow at least three links to get to examples. Some simple, immediate relevant examples will illuminate the reasons quickly.

Eric: Other bullets are specific and clear, but when we talk about these other devices we say it helps but now how or why. It is a problem by being less tangible. Must give the reader a concrete example to take and read about.

<Brent> Eric explained my initial point perfectly.

Shawn: Am also worried about the length of the list, so will leave this as an open issue.

<yatil> [ Clarity > Brevity :-D ]

Shawn: Will make those changes and have it for next week's survey.

Brent: Great discussion greatly appreciate all the good feedback.

Business case

Sharron: I am not nearly as far along as Shawn with her Intro. I am frankly stuck. It is clear to me from all the reading that community understanding and expectation for a Business Case for accessibility has evolved over time. I think our cafeteria plan as currently offered tends to be more overwhelming than helpful and feedback from conversations validates that thinking. Without academic or documented studies of some kind, it is a hard case to make with authority for those who want hard proof. Even the currently posted version makes no strong claims but uses modified phrase like "may increase market share," Could improve user experince" etc and then the article will be quoted as "proof," when it is not making that claim at all.
...so I have considered all kinds of different approaches including Shawn's suggestion to find another way to refer to it, not even try to call it the Buisness Case. Not sure that will work however since people still tend to look for that phrase.

<Chris> I think business case is a relevant search query we should leverage

<MattPutland> +1 to calling it the business case

<Brent> Current Business Case: https://www.w3.org/WAI/bcase/Overview

<Brent> Draft Version: https://w3c.github.io/wai-bcase/business-case/

Sharron:So what I would like to do is to hear from you all about what you find that people talk about or ask about in support of justification for the expense of time and effort on accessibility and how you may make the argument in countries where the legal argument is not as strong, due to lack of laws or enforcement.

Vivienne: In Australia it can be a more difficult sell because we do not have strong legal requirements. They exist but are not strongly enforced or really enforced much at all. People look for reasons to tell their organizations to invest, what are the business benefits that advocates can point to?

<Chris> +1

Vivienne: We often use user experience, increased market share, improved usability, something they can use in context of their own organization.
... organizations need help and this is a good role for EO to play. Because it is so much more loosely required outside the US
... many organziations have commited to the best user experience; agencies must make statements of diversity and inclusion.

Sharron: Are they including disability in diversity efforts?

Vivienne: Yes, it is the government that has put this into diversity and inclusion because of the high profile of the D&I efforts.
... must demonstrate how you are meeting those requirements. I agree with you that emperical studies are needed at a research level. At some point we must be able to offer proof.

https://w3c.github.io/wai-bcase/business-case/

<yatil> [ I think it is OK to have anecdotal information if it is clearly said. Also #a11y is not isolated. It can change interaction to the better, then you can't say if it was the accessibility-led usability change or that the site is more accessible. ]

<Vivienne> what about the improved mobile experience

<AMace> Device flexibility - huge driver for most of our clients

<Brent> What about cost savings

<Norah> social responsibility

<Vivienne> yes to cost savings - better download time etc.

<MattPutland> "Don't think about the cost of accessibility, think about the cost of not doing accessibility"

Vivienne: Suggest quite a bit from the leading consultants on the Accessibility Maturity Model that might be useful to us.

Brent: We have used the Paciello data in some presentations for leadership at Pearson

<Vivienne> I feel strongly that 'business case' needs to be there

<AMace> Prefer using 'Business case'

<yatil> +1 to shawn's idea

<Norah> maybe call it the business case, but business case example is only a part of the "business case"

Shawn: When it came up earlier, there was a great deal of support for keeping business case. The current version was a justification that took the approach to look at each SC and prove its value.

Eric: When I hear Business Case, I hear ROI. Actually earning money by making a web site accessible is not something that can be directly measured. It will contribute user satisfaction, and other business reasons that do not have the direct relation to ROI. maybe say "Why this is *not* a Business case" and use anectdotal examples.

Chris: To successfully create an accessibility practice within an organization you usually require a pitch, and through that a business case

<rjolly> +1 to yatil on naming it slightly different than Business Case

<Vivienne> Our customers need our support to help them develop their business case so that they can get funding.

Howard: I don't know if you have to have absolute proof in order to make the claim. Evidence or something from the TeachAccess or MS access project that could support the arguement. I am wary of changing the name, Business case is clear and familiar.

Eric: Just start to write it and then ask for the proof you need.

Sharron: This is really helpful everyone and just the kind of perspective and push I need - thank you!

EOWG face to face at CSUN

Brent:Dates will be Monday the 19th and Tuesday the 20th of March, likely to be at the Hotel Solamar

<Chris> how far is that from the venue?

<Vivienne> I wish so much we could afford to come :(

Shawn: Thanks tons to Pearson and Brent and brent for covering the costs and Sharron for making the arrangements.

Brent: Big shout out to Jan for budgeting the funding for that.

Reminder of alternating times for meetin

Brent: Look at availability survey, thanks to Vivienne for the prompt to actually make this a reality.

WrapUp

Brent: Read minutes, look at resolutions, follow work for this week, complete surveys.

Shawn: Am trying to get the resolutions and comments processed. As we try the faster pace, be prepared to comment and get these docs approved, turned around, and published.

Brent: anything else?

Sharron: OpenAIR is recruiting teams. If you know people who would like access to training and and a chance to apply practical skills, please send them our way.