Meeting minutes
Chuck: We will be starting in a few minutes. We will formally start at 2 minutes after
Chuck: We will start in 1 minute
… Please use present plus if you have not already done so
Chuck: Welcome
… We have a scribe for hour 1
… We need a scribe for hour 2. Please volunteer
… Does anyone on the call want to introduce themselves?
… Does anyone have in mind new topics?
… We keep a list for future meetings.
Announcements
<Chuck> https://
Chuck: Reminder: TPAC registration
… Please register if you intend to participate in person or remotely
… Early bird: available until August 5th, with substantial savings
… 50%
<Chuck> https://
Chuck: Also, reminder: inclusion fund and honorarium
… This can help with funding
… If you are interested in WCAG to ICT, please contact Michael Cooper
… We have not yet begun meeting, but after a few more milestones are reached we will begin
Chuck: The final announcement
… A minor change for scribing
… We will follow what Silver is doing
… We will keep a list of regular participants that are also able to scribe
… That list - we will start from the top, go to the bottom.
<mbgower> +1
Chuck: Those that have scribed recently will be moved to the bottom of the list
… When needing a scribe, this helps selecting people that have not scribed in a while
… We will be putting together this list
<jon_avila> So we need to sign up for remote TPAC if we want to attend any of the AG calls during TPAC week?
Chuck: If you feel that you are not an effective scriber, send an email to the chairs
… We will ensure you are not on the list
… This will help guide us on who to ask
… This will not increase pressure to scribe
Rachael: We are moving to implementation testing in the next week
<AWK> +AWK
Rachael: If you are willing to be a tester for WCAG 2.2 please email the chairs
… The more testers we have, the faster we can get through this
Scoping Presentation & Discussion
Chuck: Mike Gower and Francis have been working on this
<Francis_Storr> Also: Rachael and Shawn working on it :)
Mbgower: we will take questions at the end
… This is an exploratory discussion
… It will not lead to a vote
… other than some terminology
… (reviews agenda)
… Problem statement: this statement captures some of the considerations we were chasing
… (reads problem statement)
… We will talk about 2 main areas
… We were trying to touch on key concepts
… What is the smallest unit we test against
… Answer: the user interface component
… Focus appearance brought interesting questions
… All of us perceive things differently
<Chuck> Hi Ben, other than the preso link and sharing, I don't think we have an alternate version to share at this time, but I will ask when we get to Q&A
Mbgower: One lesson: even when something is subjective we can derive benefit
<Chuck> reminder to all that I will process queue at the end of presentation
Mbgower: For focus appearance: you can make something look like a button that is not coded as a button
… User centered approach: we need to understand how the user perceives these
… Another thing: sub-components
… Like menu items in a menu
… They can appear to take focus - do people perceive this as its own user interface component?
… Same thing with a menu bar, or a ribbon
… Do people perceive them as a single user interface component?
… Another question: afforances like chevrons
… If we assess this, do we need to assess smaller units?
… And, what about graphs (visual constructs)? Sound? Touch?
… Some, like text: labels are perceived by most people to be part of the user interface component
… Other things are page or process oriented
… Another important thing: we don't have to reinvent the wheel
… Lots have come out since 2.0 came out
… Ultimately: what moves us towards repeatable, measureable, consistent results
… 1 example of subcomponents is on slide 5
… Left picture: date input, with text above it.
Right picture: calendar widget, is the calendar part of the input, or more than 1?
… There is focus on the actual year - you infer you could move the year
… There are left and right arrows for moving through the months
… These are affordances - are they their own components?
… Affordances: besides all the numbers in black, one is in blue
… That is the 24th of July
… It also has a dot
… It indicates the day it is
… How best to convey what it is important?
… Native HTML input has a calendar input, but I have seen some without a calendar input - is this a failure?
… Sometimes this helps us make an assessment
… Moving on - slide 6
… This was discussed on one call
… Objective and subjective need a definition
… An exercise can help with terminology
… Objective test (reads from the slide)
… high: we debated putting 100% here
… Focus appearance: hopefully it is repeatable, and measurable, easily
… Slide 8
… Are the 2.x criteria objective or subjective?
… Our view: if it is not objective, it is subjective
… We broke out the wording
… How many do you think are each?
… Our answer: all ended under both
… I extended this to first 3 dozen
… We moved to a 5-point continuum
… Totally subjective to the opposite
… 34 fell outside the endpoints
… 1 was pretty objective, 1 was pretty subjective
… Slide 9
… 1.4.2 audio control
… Fully objective?
… 3 seconds is subjective
… But it creates a clear condition against which we can measure
… If it was 2 or 4, you still would have something to measure against
… You may end up with discussion around rounding
… The requirements are very specific
… You have an understanding of when you arrive at yes
… 1.4.9 Images of Text
… (reads from slide 10)
… Getting everyone to agree on pure definition, and essential will be difficult to get everyone to agree on
… And significant other visual content
… This is purely subjective criteria
… Those are the extremes
… Slide 11
… Non-text content could use more granularity
… (reads from slide 11)
… Example from the exercise: pulled out the objective and subjective parts
… "has a text alternative" and "that serves the equivalent purpose"
… Can we get to more objective by making a few tweaks?
… Slide 12
… Does the image have an attribute?
… Is the code good?
… Looking at it this way you start to see some truism
… You can begin to see things that help be consistent
… It is a lot easier to answer within the confines of some technology
… Whether or not there is an image tag on the page is easy to get people to agree on
… You can imply some of these concepts, and get some clarify
… clarity
… You can apply this to different success criteria
… More consistent reporting should be considered
… (slide 13)
… Do we need 1000 words to get to the equivalent purpose? And would anyone find that helpful?
… Image is a dog, with a blurry background
… But you could say a lot of things about this dog
… "Dog" may not sufficiently describe this picture
… People could have different perceptions of these descriptions
… There are many different ways to think about this photo
… If we assess for other criteria (slide 14)
… Singular vs plural - this would provide clarity
… Could discount words like the
… To get a minimum number of words
… Subject/object, or Noun/verb
… Context: is it in the user process on a dog buying website?
… Is there a caption?
… Maybe then it is more relevant
… We need to think what the page is about
… (slide 15)
… Left: a Golden Retriever running, ball in its mouth, leaves on the grass
… Right: 4 dogs, on a white background
… They all have different poses, different kinds of dogs
… The 2nd image is from an article about breeds that live the longest
… Alt text then might describe the breedds
… There is nothing about Irish Setters in the article - so surprising it is there
… Is it being in the background important?
… (makes a comment about how dogs are not that important to him!!!!) LOL - comment from the scribe
… (slide 16)
… Looking at 1.1.1
… Lots talking about short text alternative, then long text alternative
… What if there was a criteria only for images
… Text alternative: describe brief, accurate
… Research could probably arrive on what is brief
… It might not be perfect, but it could be more testable
… There could be a criteria for important images
… This could be flagged by the author
… Equivalent purpose could be used for important images
… Majority of users needs to be considered
… Discussion also needs to happen about longdesc
… Smaller set of images now need discussion around equivalent purpose
… All of this would take a lot of research
… This might get us closer to something for a subjective condition, and more objective results for 1.1.1
… (slide 17)
<Rachael> Link to exercise on slide: https://
<AWK> 0
<AWK> Completely objective = 0
<AWK> 3 sec is not subjective. It may be arbitrary
<GreggVan> "Love of my life"
Francis: Dogs are clearly important - per the chat discussion!
… (reads from slide 17)
… On slide 18 it breaks this down
… Objective tests for label in name
… (slide 19): Subjective tests for Label in Name
… what jumps out to me is the one about images of text
Mbgower: (slide 20)
… Some of the strategies that when into improving reliability
… Objective outcomes could help
… We can get to more measurable baseline
… (reads from slide)
… Changes of context: made without user's awareness
… Then there is a list of different things that constitute that
… Where do we put them? What if they are not exhausted?
… The condition itself doesn't have to be perfect
… But using them makes things more testable
<Chuck> For those who may have recently joined, I will process queue at the conclusion of this presentation
Mbgower: If you only think about a question around a component - maybe there is a way to arrive at clarity that way
… Decision trees can help
… This can improve reliability
… Things don't always break down to subjective/objective
… (slide 21)
… This slide has scoping terminology from the Spring
… We are wondering if item is really descriptive enough?
… Maybe we have a list like UIC image
… A baseline item we want to consider
… Views - page at URI or other, container...
… View seems to be something people can live with
… It seems to serve its purpose right now
… An earlier draft said processes
… That seems to have held up pretty well
… It is kind of, like view, let's us assess things beyond the component level
… Finally - aggregate
… Whole site?
… At the moment, we don't need to nail this down more
… Our view: the terminology for these are holding up
… but consider a few items
… (slide 22)
… We think slight differences in terminology would be helpful
… Usually something has a condition
… Unconditional is confusing
… 3 second audio is a condition
… leads to a consistent outcome
… I have a star by binary
… What can we get away with high reliability?
… Can the measure be 100% but not the outcome?
… For conditional: educated judgement call may change reliability
… We had some other terms, but quality and objective - if we can agreement on those, that might help
… The procedural subgroup is working on the definition
… Conventional: this is a bit of a curve ball
… This is a good point to hand this over to Shawn
… (slide 23)
Shawn: Yes, I dug into multiple ways
… (reads from slide 23)
… (slide 24)
… There really aren't any objective aspects
… This is measurable in pieces, but requires you to look at the aggregate overall
… Site map and search are in the Understanding Document, but not a complete list
… There are subjective bits
… I have some here, there are probably more
… (reads from slide)
… Can you get to every page through search?
… Do you need to know a particular title to get there through search?
… (slide 25)
… Test case
… needs context of the larger site
… This needs a test case
… The ways we can help people create test cases for their own context
… (reads from slides)
… This is now more objective
… Do all of these pages exist in the outline listed here? Needs this context built through the test case
… (slide 26)
… There are more test cases that can be built
… (reads from slide)
… There is the question of quantifying the usability of these things
… But you can build up for the full site
Mbgower: (slide 27)
… This doesn't solve all the problems, but has questions for TPAC
… (reads from the slide)
… Right now we test by failures
… What if we count what is right?
… The question about overlap - is someone classifies it one way, and another does this another way, will this be a problem?
… That concludes the discussion
Gregg: This is a really interesting presentation
… Some are historical
… Your unit of measure
… We looked at that a lot!
… WCAG 2 ICT - we looked at view
… We could never make it work
… We can talk about that more another time
… The view in web apps keeps changing
… Objective/subjective - you were talking about 3 being subjective because you didn't know the science behind it
… It was arbitrary
… Selecting it can be arbitrary
… 3 is 3 to an infinite number of zeros unless a tolerance is specified
… sounds like a bias towards deciding something is subjective
… A reliance on markup language
<Zakim> Chuck, you wanted to ask about alternate versions and to ask about "objective" testing and evaluating such
Gregg: If you make it HTML only, a lot of vagueness came from trying to make it technology agnostic
… If HTML only it will become easier to read, clearer, and everything would be more cut and dried
… But wouldn't be used anywhere other than HTML
… Purpose of a picture can only be determined by the author
… If licenses page, photo of a dog
… The purpose is to make it easy to identify the type of license (not fish)
… The purpose can only be determined by the person
… Accurate: you said 2 things that need to happen
… Code is good - you talked about trying to separate them
… We tried to make that one of the success criteria, and you had to do that one
… We didn't do reporting
… (lost his audio briefly)
… You talk about test case and test process
… They should be kept separate
… Some also have a test at the end of the document - that is an interesting thing to do
… Objective, qualitative and user process - I think that is great
Chuck: Keep comments brief; discussion is for TPAC
<Zakim> jeanne, you wanted to say This is very useful and helpful work, kudos! Did you look at the work that Test Reliability did in how to write Outcomes and Methods?
Jeanne: Excellent work.
<Ben_Tillyer> +1 to kudos!
Jeanne: Was going to ask if you had coordinated with test reliability. Is there a plan to update or include some insight in the work that test reliability did on writing outcomes and methods?
<Zakim> Rachael, you wanted to say goal is to create a temporary shared way of talking about these terms
Rachael: This presentation had 2 goals: update some of the foundational ideas for TPAC, as well as terminology to use. We don't need a perfect set of terms, but we need one we all use as we go forward.
Janina: Nitpicking about Alternative text.
Janina: 2-5 words for short would be wonderful. We tried for 50 and failed.
Janina: Missing understanding was a difference between a push and a pull.
Janina: We fought for longdesc. It became an extension in HTML5. Thinks it's deprecated. Concept of a longdesc is important. The mechanism is important.
John: Joined call late, so playing behind. A few questions
John: Fault tolerance. I have 10 images, 9 have good. It's not a pass, but is it a fail?
John: What are we testing for? Optimizied/maximized usability?
John: There is a second goal of conformance. Orgnaizations are legally mandated to achieve a level of accessibility. What's our score? Am I conformant? I'm not sure we tackled that sufficently.
John: Testing based on user needs. Which user?
John: I saw some questions on captions. There is a divergence of opinion on what constitutes a good caption. Straight verbosity? Cleaned up? It's a matter of opinion within a specific community of use. How do we get around that?
Subgroup Intros and Q&A
Chuck: Conversation can occur asynchronously, and can take place at TPAC.
Shadi: Test types and terminology. This ties very nicely from the presentation.
<shadi> https://
Shadi: There was one slide on test types and terminology. We are a group of 4, but haven't all been able to meet. Still a bit choppy. Started looking at the background.
Shadi: In section 4 at the top of it, there is an editor's note with lots of useful information.
Shadi: The approach we decided is to go with the existing test types in 2.x.
Shadi: We've done 2 of the 4. We are coming to the conclusion of "qualitative" or "computational". Not to be confused with automated. It's early on, so please don't jump on the terms.
Shadi: We do hope that we will also identify potential gaps.
Shadi: midway we would like to come back and present to group.
Shadi: We meet Monday's at 8am Eastern US.
<shadi> https://
Francis: Issue severity
<Chuck> Thx Shadi!
<Rachael> Issue severity: https://
Francis: We meet Wednedsay at 8am Eastern. Started with a round of introductions. Started with core questions. Working document lists out current methods and user impact.
Francis: Tomorrow's meeting follows week 2 structure in the handbook.
Francis: Planning to do a mid- presentation. Alastair is away but everyone else should be there.
<Makoto> Accessibility Supported Sub-group https://
Makoto: Accessibility support has meeting on Tuesday 8am Eastern. 9pm for me.
Makoto: We had our second meeting today. ONly 2 participants this week. Last week 4. There are 6 persons. We might need more participants. Have not finalized goal yet. Today AWK and me agreed with the possible goal.
Makoto: To present pros and cons on two options: 1) keep accessibilty Supported 2) not keep Accessibility Supported. We will put together concepts and discuss 2 options.
<Makoto> Starting document "Accessibility supported in WCAG 2" https://
Makoto: We have some anonymous comments. If you wrote your comments, please let us know which are yours.
Makoto: Starts with wcag 2 use. I added how Japan is adding information
Makoto: Other members might be able to more. Such as how Adobe supports Acc. Supported. How 508 supports, etc. Then we will discuss pros and cons.
Makoto: We need to reach concensus.
<Chuck> mbgower: Mention that IBM created it's own SC to measure that, it's been useful for people doing testing, when they don't know why for instance screen reader isn't working.
<Chuck> mbgower: It's useful for when you are testing and you don't know why but you know something is wrong with supporting.
<jeanne> Equity Subgroup
Jeanne: Last week we reveiwed the research from Silver around equity. Goals: define, evaluate level of support; the challenges; the challenges from time frames; biases.
Jeanne: Met yesterday and discussed definition.
Chuck: TPAC agenda is in process
Rachael: Thanks for the subgroup work.
Michael Cooper and John Foliot have presentations on work done in protocols for next week.
Short and brief subgroup updates will probably be added to the agenda.
Silver Task Force Transition
Rachael: As part of the charter, we planned to close the Silver TF. Still a few months left and a few pieces to consider.
Rachael: We wanted to run through some key considerations. Not a decision today but start of conversation
Rachael: What are the goals and work? Update and consolidate Guideline writing process
Rachael: Also reviewing WCAG 3 content before it comes to WG.
Rachael: Second question is around Friday call time. Working well, so intention is to keep, but will officially be an AG time slot.
Rachael: very much a working meeting
JF: I wanted to express a concern about time commitment. Already dedicating 2 hours per week in Tuesday. Friday not working for me. Concerned about amount of time.
JF: Is intention to reduce Tuesday call to 2 hours.
Rachael: Intention was to keep Friday for folks who can come. Smaller working meeting. Actual final decision made on Tuesdays.
<Zakim> jeanne, you wanted to invite the Scoping people to attend a Silver meeting and talk about how we can incorporate their insights into the Guideline Writing Process
JF: Decisions on Friday will have to be redone on Tuesday. There's a lot of circling back that has to come.
Jeanne: A different topic. I would like to invite the scoping people to come to a Silver meeting.
Gregg: I wanted to echo. I was concerned about breaking into the small groups, but thought I'd watch to see what happened.
Gregg: It's frustrating to work on something and have something later come apart. I would always allow anyone to join, but make sure that anyone had a strong opinion was on it -- including anyone who was opposed to an approach.
<JF> +1 to Gregg
Gregg: Working in small groups only works when the key players are involved.
Gregg: You're going to have a lot of time with people without the voices they need. They can feel like it's a waste of time.
<JF> +1 and we've heard about this problem directly before
Gregg: I thought with slightly bigger groups maybe, but smaller groups are running concurrently.
<GreggVan> +1 to that comment from Michael
Michael: I hear concerns about the groups. Chairs have found subgroups offer a way to getting things done where the larger group is having difficulty.
Michael: The subgroups mission is to do a little sprint and help the larger group move forward. It's a challenge, but I think it's better than other things we've tried.
<GreggVan> good luck tough nut
Chuck: We're talking an approach we think has the greatest success, but realize it is not perfect. Noted concerns, and hope we can accommodate.
<Rachael> Rachael: Will be retrospective on subgroup process at TPAC
Rachael: What will happen to the Silver Community Group
<Chuck> Mike we appreciate your scribing efforts, very helpful!
Rachael: lists the actions of the Silver Community Group
… we want continued engagement
… there will be some issuess, such as the Patent Policy, that need more research and discussion
Revisiting Functional and User Needs
Rachael: WHat will happen to the taskforce facilitators? Jeanne and Shawn continue on the leadership as editors
MC: Functional Needs group has formally moved to APA.
… continuing to refine the functional needs
… input from Childrens Accessibility Community Group
… input from COGA
… probably will not have @@ ready before TPAC
… intend to stay in touch with AG
… Outcomes apply to Authoring and User Agents
… expect to have a list of OUtcomes for AG -- not to be automatically included, but to support the work
<JF> sounds like an intersection of Accessibility Supported and Scoring/Scoping
CA: How useful was it? Is it too detailed or not enough?
MC: People who worked on the Categorization Exercise gave feedback that they were hard to work with
… we understand the challenges and are looking to improve the usability of the list
<Chuck> jeanne: One of the things... I worked with this list a lot. I've done a lot of the sc that went through exercise. The granularity of different sections of functional needs does not seem equivalent.
<Chuck> jeanne: I would like to ask for review the functional needs granularity for an even-ness through them, so that they are more usable.
<Chuck> jeanne: We could use for an equivalent evaluation. Granularity for reviewing new guideilnes, would be helpful for consistency.
JF: I am trying to understand the different beteween functional needs and functional outcomes? Is the EN 301 549 & Section 508 requirements included in this discussion?
<MichaelC> https://
MC: We definitely having challenges with granularity and need to address it.
… Functional Needs are being moved into FAST and it is less granualar
MC: Functional Needs vs User Needs -- some of it came out of a desire for affirmative positive phrasing of what the user needs rather than the barrier
CA: Do we have a means of providing APA the feedback?
MC: Normal comment procedures -- contact members of group or make comments in the spec
Rachael: Michael, can you talk more about how you see these being used?
MC: The Functional Needs is meant to become a comprehensive list of all the touchpoints of accessibility
… we have only documented the needs that cross the accessibility space
… having a comprehensive set of functional needs helps us not leave anyone out
… this approach may catch accessibility use cases that we may not otherwise identify
… this will also be included in the FAST - the accessibile specification technology spec
<JF> bye all
<Chuck> Thx!