Problem statements

<jeanne> ACTION: Jan will draft problem statement for including more disabilities

<trackbot> Created ACTION-149 - Will draft problem statement for including more disabilities [on Jan McSorley - due 2018-01-19].

Jeanne: Is there anything else that we need to document in conformance. We can always prioritize our list as well.
... Let's look at usability next

Shawn: Some of the themes are good, but some of the statements are talking about solutions, rather than defining the problem - such as we need better search - the problem is that people have difficulty finding what they need.

Jeanne: We pulled the following four themes out of the research: Difficult to master; Ambiguity in the SC; Convincing others; Too technical

Kelsey: I feel like convincing others is a major challenge

Jeanne: Is there anything in "difficult to master" that is unique? Are the concerns covered in ambiguity or too technical

John: I found it hard to wrap my head around the structure: principles, guidelines, SCs, success or failure off the SC, etc. Knowing how to use the structure is important, but it's difficult to learn; the cross reference on the site has made it better, but there are so many articles that it's difficult to find what's relevant and current
... some people jump straight to the SCs without understanding the structure; e.g. we had checklist that were organized by elements, rather than by the structure of WCAG
... knowing that you can tap into SCs at different levels is really important.

Jeanne: The WCAG 2.0 quickstart was an outline of the document with plain language quick points - this was useful, but don't think it's still in use

<jeanne> Jeanne: WCAG at a Glance: https://www.w3.org/WAI/WCAG20/glance/

Shawn: Is the difficulty to master, a problem that we need to solve - as opposed to solving the onramp issue - the learning curve is too difficult to master - making progress toward understanding is important (e.g. making things easier to read), etc.

Charles: I agree - do we want to scrap the difficult to master problem and replace it with more of an onboarding / getting started?

+1 to Charles' suggestion

Kelsey: Part of the challenge is even understanding what is at each level and then moving on to highter levels of conformance.

<Charles> Charles will review the “usability » difficult to get started” problem statement over the weekend

<jeanne> ACTION: jeanne with Charles to update the Difficult to get started problem statement

<trackbot> Created ACTION-150 - With charles to update the difficult to get started problem statement [on Jeanne F Spellman - due 2018-01-19].

Jeanne: Is the ambiguity problem statement okay? If you want to make changes, please feel free to edit.
... please make edits to anything here and you can assign yourself to revising something if you feel like you need it; we haven't looked at too technical yet

Charles: "Too technical" needs to extend to the difficulty in translating it because of the language that is used.

Kelsey: Is part of the problem that it's hard when getting into the weeds of the SC if you don't understand the themes of the structure. Maybe if people understood the themes better, the guidelines would be easier to understand.

Jeanne: Part of the reason it is written the way it is written is that the belief was that it would be better adopted by regulatory agencies with this language.

John: a11y starts with developers - when people are in the thick of it, they want examples and they want code and then when they get more time, they could be back to understanding the structure.

Jeanne: We have to have better requirements for how to write the requirements so that they are understandable.

Kelsey: For example "keyboard trap" is understandable by a person with experience, but a person who is new to accessibilty may not understand what it means.

Jeanne: True, and the examples and solutions need to consider different delivery systems, e.g. mobile

Shawn: There are problems that are onramping issues and there are issues that are language issues

Jeanne: Maybe we should be looking at 2 problems instead of 4 (information architecture and wording and writing style)

Shawn: It think it's different aspects of usability; conformance model is separte from usability issues - it is effected by information architecture, but not inherently tied to it.
... understanding ties into information architecture; WCAG was arranged in its current structure to help people understand it better

Jemma: Shawn's point is important: information architecture can overlap with the design problem - this is a good way to summarize and needs to be written down

Kelsey: Have you seen a trend of people wanting to do the bare minimum in order to meet accessibility, but then missing why it's important - that is part of the challenge.

Jeanne: Two audiences: How do you serve the needs of people with disabilities while also supporting companies that need evidence of conformance to defend themselves from legal challenges.
... how do we design a flexible structure that meets the needs of both audiences?
... There is a real-world practicality that some companies are not going to address a11y unless they are forced. For this reason, we have to have a conformance model that will measure the minimal compliance, but we also need to look at how we can also meet the needs of disenfranchised groups of people with disabilities.

* my pleasure :-)

John: some people who are unfamiliar with accessibility are prone to approach A and then AA, etc. rather than looking at the show-stopper blockers and fixing those.

Jeanne: Originally, A, AA, AAA was supposed to be structured to support people addressing show-stoppers first, etc., but technology moved on and now the A, AA, AAA doesn't mean what it was originally intended to mean

Kelsey: There seems to be more focus on screen readers than other types of access

Jeanne: Do we want to put that under the maintenance issues we want to talk about?

<kelsey> address assistive technologies that aren't a priority: for example ZoomText

<kelsey> (add to maintenance section)

Shawn: We should go through the maintenance section and write down what the issues are that need to be addressed; I can go through and document some of the issues that we have seen as 2.1 has unfolded - not everything is research-based, but has been gathered anecdotally

Jennison: We need to talk about acceptances of participants on Tuesday

Jeanne: I will work on the process description

<jeanne> ACTION: Jeanne will draft the process problem statement

<trackbot> Created ACTION-151 - Will draft the process problem statement [on Jeanne F Spellman - due 2018-01-19].

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)

Present: Jan Charles Jeanne JohnM Shawn Shari JaeunJemmaKu
No ScribeNick specified.  Guessing ScribeNick: Jan
Inferring Scribes: Jan

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 12 Jan 2018
People with action items: charles jan jeanne with

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)