Meeting minutes
<jeanne> https://
<Francis_Storr> Same comment for me as Chuck, I'm afraid. Juggling home schooling and this.
Wilco: Notes we're doing a deep dive from a test perspective
<jeanne> Survey
wilco: Goal more on what do we learn from this deep dive that applies to this outcome, but also others yet to be written
jeanne: Suggests carefully walking the outcomes and also the received comments
Wilco: Will go question by question
<AWK> +AWK
jf: Asks for high level overview of ACT rules and atomic rules -- for those of us not sufficiently familiar
Wilco: Any objection?
<Lauriat> +1
jeanne: Should be helpful esp for Silver folks
Wilco: Generally speaking -- "Accessibility Conformance Testing" == ACT
Wilco: A project name for work several testers started some years back
Wilco: Problem is that we were getting different results--not good
Wilco: had to do with sampling, but mostly how we interpret
Wilco: WCAG intends to be tech agnostic
Wilco: Uses an abstraction, and that abstraction then requires a translation to apply to a particular technology
Wilco: Differences occur in that translation process
<Zakim> JF, you wanted to ask about ACTY rules and formats other than HTML (web)
wilco: What's a lang tag? What's an image? What's a heading?
wilco: Goal was to harmonize testing WCAG 2.x
Wilco: We created ACT Rules -- most common unit of test
Wilco: An ACT Rule is a predefined tech specific of what's required for WCAG
Wilco: So is ACT Rule for "does this HTML page have a title?"
Wilco: We also wanted to ensure consistent use is possible
Wilco: And adopt for testing platforms
Wilco: Trusted Tester is an example
Wilco: We make sure of consistency with test cases; shows when a rule passes or fails
jf: Asks for comparison of headings in html vs pdf?
Wilco: Could, but ACT has not focussed PDF
Wilco: our expertise is html
jf: Any rules today outside of html?
Wilco: Nothing officially published; though some efforts on epub and pdf
Wilco: Other questions?
[crickets]
jeanne: Shares screen for survey ...
jeanne: Notes in wCAG3 has been iterative process where we circle back over all aspects of the emerging doc for over two years
jeanne: We started with guidelines we had, then worked on scoring
jeanne: Starting from the all day mtg with WCAG
jeanne: what we have is by no means complete
Wilco: Much effort went into creating what we do have; so let's not focus on what's missing
Wilco: Rather on what's correct and not; and how to iterate improvement on what we do have
jeanne: Guidelines are high level; very similar to WCAG guidelines
jeanne: Reviews the pieces incl auto failures vs reviewed failures
jeanne: Sometimes normative statements get repeated in informative sections
jeanne: Talks about disability categories noted that apply. Important because each category will be individually scored to get the overall score for conformance
jeanne2: We're trying to ensure no disability category is left behind
jeanne2: We can certainly write more methods
jeanne2: These important distinctions to figure out where testing info goes
jeanne2: Turns to survey
Deep Dive into a single Outcome - Headings organize content
jeanne2: Looking at DM's survey
jeanne2: visual distinct problem--let's circle back on that
<AWK> Can someone post a link to the survey?
<jeanne2> https://
<Chuck_> https://
david: Assuming evaluate process and decide whether there should be a heading where there's not one?
Sheri_B-H_: how else to decide whether a heading is missing?
Sheri_B-H_: Answer is "yes"
Sheri_B-H_: not on what it should be, but that one is missing
<Zakim> JF, you wanted to ask how do you know if there is a heading missing?
<jeanne2> question+ How to determine that a heading is missing
Jennifer_strickland_: Wanted to state that current content is still being reviewed -- still where it was a year ago. We know we have work to do
Sheri_B-H_: Correct that there's not been plain lang review yet
Jennifer_strickland_: Or that content is all there
jeanne2: Yes, we're in an iterative process
jeanne2: Suggests DM's comment more a critical failure issue ...
jf: How do we know whether a heading is required? Is there an applicable rule?
<AWK> Is there a threshold for what constitutes a critical failure, in general? I don't think that a missing heading is a blocking issue.
<Chuck_> sajkaj: Some of my comment is related to that.
jeanne2: Notes we'll revisit if we discover we need more normative guidance
Wilco: My comments-- much hinges on what a logical block is
Wilco: Curious to hear ideas
Wilco: We need definitions
<Jennifer_strickland_> +1
<Chuck_> A section contains controls or information grouped by a theme or purpose which is distinct from the themes or purpose of other sections within a view or process.
Chuck_: Have an alternative for section
<JF> Do all <divs> (a sectioning element) require a heading?
Chuck_: Reads his proposal
<Chuck_> Original: A section is a self-contained portion of content that deals with one or more related topics or thoughts.
Chuck_: May be themes, e.g. nav,
Jennifer_strickland_: Agree we need to define what belongs in a section block
<bruce_bailey> HTML Section Element (<section>) defines a section of a document to indicate a related grouping of semantic meaning. It makes sense to use the section element to provide extra context for the parent element.
Jennifer_strickland_: we need to consider what the actions are
<JF> -1 to having too many headings
Sheri_B-H_: example is a survey -- examples of text then some buttons to select
Sheri_B-H_: so every section we need headings
Jennifer_strickland_: better headings definition could help
<bruce_bailey> https://
<bruce_bailey> The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.
<Chuck_> Proposed: A section contains controls or information grouped by a theme or purpose which is distinct from the themes or purpose of other sections within a view or process.
Jennifer_strickland_: phps we need to be requiring a heading per page
<Zakim> bruce_bailey, you wanted to ask to look at current HTML def for section
bruce_bailey: think our concepts are actually html, even though we hope can be applied beyond html
jeanne2: asking whether more precise definitions would help the ACT level
jeanne2: or do we need rules at the tech neutral level
<JF> Yes to Jeanne's question
<Zakim> jeanne, you wanted to ask if better definitions are sufficient, or should we have technology neutral rules at the Outcome level?
jf: concerned that too many headings will have a negative impact on some users
<AWK> Bruce, Section in PDF Spec: A container for grouping related content elements
jf: think we need appropriate titles/labels, but not nec a heading
<Jennifer_strickland_> The section element is a neutral HTML element, and the definition we're discussing here as sectioning is a bit different. The section element in html has only minimal difference from a div, for example.
Sheri_B-H_: not advocating, just trying to extend Chuck's suggestion in the moment
Jemma: not sure we need rules on the outcome level
Jemma: but we need some kind of definition in the outcome
<jeanne2> Thanks, Anne, that is very helpful
Wilco: ACT ruiles tend to work best when normative requirements are well defined
<shadi> +1
<Zakim> Chuck_, you wanted to say I'm a fan of Bruce's comment. No need to create new definitions. And to ask about how WCAG 2 handles this.
<MelanieP> +1 to wilco
<CarlosD> +1 to wilco
<JF> +1 to Wilco - clearly defined Outcomes is critical
Chuck_: if we need clarity for purposes in the outcome ... redefining existing definitions may be problematic
Chuck_: we need not regress, but not necessarily improve
<Zakim> kathyeng, you wanted to say yes to definitions in outcome
Chuck_: It's not imperative to do better
kathyeng: Agree on helpfulness of definitions; hard for test authoring
kathyeng: the more well defined the definition; the easier to write test
<JF> +1 to focusing on "semantic" structure (versus just "sections")
<jeanne2> I would like to warn that we don't want to define by HTML, we have to be technology neutral
<JF> Do all <divs> (a sectioning element) require a heading?
<Jennifer_strickland_> Yep.
shadi: more testability was one goal of wcag3
<Jennifer_strickland_> (Yep was a response to Jeanne re tech neutral; would not be a response to JF)
shadi: known issues should be improved -- better definitions so better rules
jeanne2: asks about definitions in tech neutral
shadi: worried about definitions to support testability
<Wilco> +1 to Shadi's comments though
<Zakim> Chuck_, you wanted to ask about Jeanne's proposed resolution
Chuck_: looks like def tailored to support the outcome
Chuck_: support the concept--but should we call that out?
jeanne2: agrees defs could be specific to outcomes and would allow more precision at tech neutral level
jeanne2: like that idea
jf: Want to +1 the idea of semantic
jf: believe we're trying to ensure strong semantic structure in whatever content we're reviewing
<jeanne2> <sajkaj> kathyeng: the more well defined the definition; the easier to write test
<ChrisLoiselle> need to drop for a client / customer meeting. Great work by all!
<david-macdonald_> I'm here now and can speak to my points
Wilco: my second comment is on consistency ... phps should be more clearly spelled out
Wilco: also why only headings? There are other mechanisms
Jennifer_strickland_: agree all needs reviewed and further developed
Wilco: notes organizing text doc is one kind of content; but there are others
<JF> @wilco, or maybe not. And let's not forget <div role="heading" aria-level="2">
Jennifer_strickland_: I think heading in this group are automatically thinking <hX> or <section>
Jennifer_strickland_: those may have different definitions depending on the tech involved
<JF> and a) ARIA is intended to be tech-neutral, b) ARIA sematinces override native semantics. I realize this is part of "testing", but still...
Sheri_B-H_: but that suggests not using different definitions for commonly understood terms
bruce_bailey: suggests trying to use words similar to headings that are familiar -- at least for now
bruce_bailey: words not appropriated by html elements might be a good approach
david-macdonald_: recalls we had talked about web unit
david-macdonald_: recalls the adoption of "horsepower"
david-macdonald_: this to say that terms can survive into a different context
<JF> +1 to DAvid - this is touching (a bit) on "Plain Language"
david-macdonald_: if we have real examples of using something other than headings, that would be helpful
<jeanne2> The Method lists exceptions of when the heading would not be needed
<bruce_bailey> with apps, could have window TITLE that serves as HEADING
jennifer_strickland_: want to call out the way we are using certain words in our outcome language at the beginning to inform how we refer to things. doing some user research w/ lay-people might be very helpful
jennifer_strickland_: we all think headings and title and labelling is how we talk about these. but what does a novice web dev or QA person think. the verbiage they use may be more plain language
<Zakim> mbgower, you wanted to say there are 500 years of typographic convention
mbgower: I think that type of convention is very much in what david was saying. title on the outside of the book, heading marks the topic of content
<Jennifer_strickland_> +1 to Mbgower
<jeanne2> +1 to MGower
mbgower: Going back to that seems to be a good way forward, most easily understood coming from a print background
wilco: want to get a bit away from this, but think it something valuable to explore
<jeanne2> question+ Finding the right word for a definition is important?
jeanne: finding the right words is important
<Zakim> JF, you wanted to note that "heading" has already been normatively defined by WAI - https://
anne_thyme: for the people writing these outcomes, recommend looking at the glossary list of the act rules repo since it will help with the things not defined in current wcag
<JF> https://
JF: We already have a normative heading definition from aria. question is if we accept that definition or create a new definition. Think that we shouldn't reinvent the wheel
<jeanne2> Thanks, Anne - very helpful. Can you drop a link to that so we can add it to the style guide?
<bruce_bailey> A heading for a section of the page.
<bruce_bailey> Often, heading elements will be referenced with the aria-labelledby attribute of the section for which they serve as a heading. If headings are organized into a logical outline, the aria-level attribute is used to indicate the nesting level.
CarlosD: Wanted to bring attention with why headings are the only way to locate content. Whitespace is a way to organize, heading is a way to organize and describe content, so don't think headings are the only way to do this
jeanne2: thats a good point, the examples in the method show how to use whitespace in a text-only document. wondering if it should be at an outcome level
<JF> +1 to Wilco
<bruce_bailey> https://
wilco: my last point on "makes locating and navigating info easier and faster", putting in normative means that headings actually make something easier or faster. I don't think that is part of the intent and so shoulnd't be normative
<jeanne2> question+ Should examples atthe Method level move to the Outcome level? The example is using white space to to separate content.
<CarlosD> +1 to Wilco
<shadi> +1 to Wilco -- this belongs as background/rationale
<bruce_bailey> A renderable structural containment unit in a document or application.
<MelanieP> +1 to wilco
<bruce_bailey> Note: section is an abstract role used for the ontology. Authors should not use this role in content.
jeanne2: Aron comment, logical blocks and expected headings need more definition
jeanne2: Jennifer Chadwick question on functional categories compared with functional needs.
MichaelC: no, they are making a clear distinction between them. we will have more to explain to the group soon
jeanne2: janina asked about other semantics serving the same purpose as headings
janina: know of many examples where there can be a mixture. I think it can go all the way back to views and accessibility support. Perhaps more requirements on AT.
anne_thyme: question on what types of headings, visual, semantic, or both. Think they are a lot more than the aria-definition. Was not clear how to test outcome just from description. Many different interpretations
jeanne2: We do have other outcomes for visual and semantic headings. This was common to both. Would it be better to have that be part of the outcome on visual and semantic headings, or have basic concept that is extended
<mbgower> From 2.4.6 Headings and Labels: "This Success Criterion also does not require that content acting as a heading or label be correctly marked up or identified - this aspect is covered separately by 1.3.1: Info and Relationships. "
anne_thyme: I think it just needs to be clear that it applies to both. For rating could be hard to count with different number of visual and semantic headings
<shadi> +1 to Anne
<JF> +1 to Anne
anne_thyme: Need to know number of objects that are included for counting to get consistent scoring
<jeanne2> question+ How to include the counting for scoring and the way different circumstances can be counted. What to do when the count is not the same across different outcomes?
sheri_B-h_: Been spending a lot of time with ML with headings but do believe we can automate solutions for some of those.
anne_thyme: Nice to hear it may be able to be automated, but need to make sure the different automated tools get same results. Goal of ACT-Rules
Sheri_B-H_: hoping to say that once we get the solution we can automate so everyone gets the same result
<bruce_bailey> +1 to davids comment, i am now not a fan of tallies
david-macdonald_: Has concerns about the counting the number of passing events for headings. It seems like it would double or triple the amount of time needed to check headings.
david-macdonald_: would increase cost to company and if budget stays the same could negatively impact accessibility.
<alastairc> We can explore options for that in the upcoming AG work
<Zakim> JF, you wanted to speak to tests and scores
JF: When we get to ACT tests, not all tests are applicable in all instances. Native mobile apps don't have notion of different levels of headings. Would be running different tests compared to web.
JF: Think about ACE EPUB tool that shows hierarchy and potentially shows missed headings.
<Zakim> Chuck_, you wanted to ask if ACT rules do this now for WCAG 2 headings
JF: We have a high level requirement for headings that are understood and methods and we need to keep those notions separate.
Chuck_: Does ACT have tests that help identify if headings organize content
Wilco: Nope, we have other rules for headings, but not for this
<Zakim> AWK, you wanted to say that without more clarity on the conformance model I think that it is premature to say that there is general agreement on counting things.
<Zakim> bruce_bailey, you wanted to say counting might be ACT related
bruce_bailey: Not quite ready to drop tally counting. One of the big differences between ACT and Trusted Tester is that ACT really tries to be machine countable.
Wilco: As a clarification, ACT rules don't need to be automated and several are not automatable.
Rating & Critical Errors sections of Headings organize content
<jeanne2> questions?
<JF> Does every test unit (view?) require at least 1 heading
jeanne2: Have collected questions from this discussion
<AWK> Jeanne should refresh survey
<Jennifer_strickland_> Thank you, Wilco, for clarification on ACT.
jeanne2: put up proposal for defintion (see above)
AWK: so the resolution is saying that the outcomes need to have definitions not that they are good right now?
jeann2: yep exactly, we are trying to take a specific example and generalize to the rest of the document. In this case we are talking about creating precise and testable definitions. The definitions may be customized per outcome
jeanne2: want to work with ACT to ensure good definitions that are testable
AWK: So outcome and questions would both be normative?
jeanne2: yes
shadi: part of the phrase "at the technology nuetral level", its not really assisting testing, not sure there is tech agnostic testing
shadi: feel there is a bit too much focus on testing. we also want this for developers to know what to do
<AWK> If content is organized into sections visually that would be tested using technology-neutral tests. Like General techniques today
<Wilco> +1
<Lauriat> +1, Shadi covered my point better than I would have.
<Zakim> Chuck_, you wanted to say "customizable" definitions may have issues.
Chuck_: I think there are some problems with creating our own definitions. Perhaps worth exploring if the definitions are technology specific. But need to be very careful
<shadi> [[That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise.]]
jeanne2: Agree and think that the best way will be for us to try it out. Hoping to prototype it for the meeting next week
shadi: Put updated proposal above
<jeanne2> question+ How to prototype the definitions so that we can see if customizable definitions work.
<jeanne2> Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise.
<Wilco> +1
<Jennifer_strickland_> +1
+1
<jeanne2> +1
<sajkaj> +1
<david-macdonald_> +1
<kathyeng> +1
<johnkirkwood> +1
<CarlosD> +1
<JenniferC> +1
<Chuck_> +1
<Francis_Storr> +1
<ToddLibby> +1
<Lauriat> +1
<aron> +1
<MelanieP> +1
<Ben> +1
<anne_thyme> +1
<Daniel> +1
<JF> +1 to Bruce's point!!
bruce_bailey: +1 on that, but also ask that the resolution include not having terms conflict with aria
<ToddLibby> +1 to Bruce's point
<Jennifer_strickland_> I presume that is part of the working with Silver + ACT to define terms.
Wilco: I think that is going to be very difficult. Headings is defined in aria and this outcome for WCAG 3 would not work as well with the same definition. Good to keep in mind, but don't think we can definitively say.
<Chuck_> Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will try to avoid conflicts with existing definitions.
<JF> -1 to Try
bruce_bailey: Looking for weakest form of compatibility.
Chuck_: Proposed new resolution (above)
<Chuck_> Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will attempt to harmonize with existing definitions.
bruce_bailey: Looking for harmonization for not to conflict
<JF> this is a scoping discussion
<bruce_bailey> characterization we used to use is "harmonization"
jeanne2: we are going to try over the next week and see how it goes.
<bruce_bailey> but our experience with 508 reg writing is that we only really need "does not conflict with"
Chuck_: Everyone +1'd the first proposal, bruce could you live with the first proposal
<bruce_bailey> -1 it is not complete enough
<bruce_bailey> does not contradict?
shadi: instead of not conflict with, could we have explaining the relation to others in case we have to contradict
<sajkaj> +1 to Shadi's principle noting that ARIA is screen reader specific
<Chuck_> Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will document relationships to existing definitions.
<Jennifer_strickland_> Please no more jumping queue. It is not fair to those of use following the rules of engagement.
jeanne2: I like the approach, it gives us a lot more flexibility.
JF: Generally i think shadis proposal is better. This is a conflict resolution, don't want to redefine words that have existed for decades
… like showing the relationship but don't want to redefine.
<Wilco> +1 this is a very complicated topic
jennifer_strickland_: I don't think we will able to come back with good definitions w/ ACT in one week.
… more useful to include more diverse experiences in definitions
<ToddLibby> +1 to Jennifer's point
<johnkirkwood> +1
<sajkaj> +1 to not over-require a one week deliverable
jeanne2: wanted to experiment with the customizing of terms for different outcome. certainly not a final definition
<Jennifer_strickland_> Thank you! <3
jeanne2: withdraw on suggestion since people think this will be hard
<bruce_bailey> i can live with inconsitency
<shadi> +1
<Zakim> AWK, you wanted to also request that the definitions never conflict with PDF spec definitions
<Wilco> +1
AWK: like shadis proposal. concern with trying not to contradict other definitions. for technology agnostic will have to look at many things and can't guarantee no inconsistency
<Chuck_> Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will document relationships to existing definitions.
<mbgower> +1
<sajkaj> +1
<Wilco> +1
<bruce_bailey> +0
<anne_thyme> +1
<Jennifer_strickland_> +1
<MelanieP> +1
<johnkirkwood> +1
<aron> +1
<CarlosD> +1
<Chuck_> +1
<Ben> +1
<Lauriat> +1
0
<JF> I would like to see something about not redefining or creating conflict
<ToddLibby> +1
<david-macdonald_> 0
<Jennifer_strickland_> I think that is addressed with the 'document relationships to existing definitions' but your mileage may vary.
<Daniel> +1
<Chuck_> Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will document relationships to existing definitions to avoid conflicts.
JF: Would like to be aspirational and bring things together but that it does not become normative.
<AWK> Definitions are normative. Avoiding conflicts with other document's definitions is the aspirational part.
<JF> "That the Outcome (technology neutral) level of WCAG3 have definitions of key terms that are aspirational, but is not in itself normative.
<bruce_bailey> Proposal: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, document relationships to existing definitions, and endeavor to avoid contradictions with terms defined by WAI-ARIA, HTML5, and related standards.
<Jennifer_strickland_> Have we ever tried to schedule rotating scribes?
<JF> endeavour sounds like a SHOULD, I'd prefer a MUST
<JF> (ref: RFC 2119)
Jennifer: It would be good to share the responsibility.
Jennifer: of scribing.
Jeanne: Recap Bruce's proposal.
Jeanne: <read's Bruce's proposal>
JF: Definitions of "should" and "must".
JF: Strike "endeavor to avoid", and make it "will avoid". We need to succeed.
<jeanne2> Proposal: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, document relationships to existing definitions, and endeavor to avoid contradictions with terms defined by WAI-ARIA, HTML5, and related standards.
<jeanne2> Proposal: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, document relationships to existing definitions, and avoid contradictions with terms defined by WAI-ARIA, HTML5, and related standards.
Jeanne: We are trying to capture ideas, this is word-smithing.
<Jennifer_strickland_> I think it's useful for holding our feet to the fire.
<AWK> JF - "The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119]."
<sajkaj> -1 to JF's proposal. We're talking about a draft deliverable due in a week
Jeanne: <read's latest proposal>
<Jennifer_strickland_> We are not delivering this in a week.
Jeanne: <recaps comments in irc>
<JF> +.65 (I can live with) current proposal
<AWK> Is PDF a "related standard"?
<Jennifer_strickland_> Silver structured content sub-group can't deliver it in a week. Unless I'm missing something.
<JF> STRONG -1 to endevour
Jeanne: Once we say "we absolutely will avoid" will tie us in knots. I want to go back to Bruce's proposal. This is not an issue we are deciding for all time, we are trying to work incrementally forward.
<jeanne2> Proposal: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, document relationships to existing definitions, and endeavor to avoid contradictions with terms defined by WAI-ARIA, HTML5, and related standards.
+.9999, we are "trying" this out.
<sajkaj> +1
<JF> -1
<AWK> -1 unless we make the list of specs to avoid contradictions is genericized.
<aron> +1
<JustineP> +1
<bruce_bailey> +1
<Lauriat> +1
Jeanne: +1 if you can accept, -1 if you can't live with.
<Francis_Storr> +1
<Wilco> +1
<kathyeng> +1
<trevor> +1
<jeanne2> +1
<MelanieP> +1
<Ben> +1
<Daniel> +1
<bruce_bailey> to AWK comment, PDF is a related standard
<anne_thyme> +1
<bruce_bailey> in my view
<ToddLibby> +1
<mbgower> +1
<johnkirkwood> +1
Wilco: I'd like to proposal that we resolve in 2 minutes or we do not resolve.
<AWK> Bruce, is that your view or everyones?
<sajkaj> Suggest last straw poll is actually consensus
<JF> It's more than just wordsmithing - we need to be precise'
<bruce_bailey> just my view
<Jennifer_strickland_> +1 that PDF is a related standard
Jeanne: Comment on PDF as a related standard.
<sajkaj> As is epub
<Jennifer_strickland_> I will now cast my +1
<bruce_bailey> i respectfully disagree that last straw was concensus
<JF> as are native apps
Methods & Tests - Relevant headings
Rating & Critical Errors sections of Headings organize content
Jeanne: Going back to WCAG doc. Headings organize content.
Jeanne: <reads> ...one or more headings necessary to complete the process are missing.
Jeanne: In WCAG 3 we look at things by view, a term for what you can see on screen, in viewport. We must be aware of 360 degree VR products.
Jeanne: the term is our best estimate. Let's avoid discussing if it's the right term. We have views and processes. Process is the task trying to be complete on page.
Jeanne: We are allowing orgs to not be perfect and still conform. We also want to capture the critical errors. The things that are severe blockers.
Jeanne: We are doing in 3 ways. 1 is the non-interference SC. If these occur any where, it's an automatic failure.
Jeanne: Flashing, automatically playing audio, basic non-interference.
Jeanne: 2nd ... the user cannot complete the process they are trying to complete on the view because of an accessibility error.
Jeanne: 3rd type is accumulative impact of small errors that sums to a complete block of completing process.
Jeanne: We are looking at 2nd category <reads>
Jeanne: Headings necessary to complete the process are missing.
Jeanne: Wilco says <reads> make it easier to find content, but "necessary" seems too strong.
<JF> +1 to that. Since a process is any activity the user performs (or can potentially perform) does this then mean that clicking on any and all hyperlinks starts a process? And if the user clicks on a link, and arrives at the intended destination, is that a “successful” process execution?
Jeanne: Sounds like a key issue.
Wilco: I want a better explanation behind it. What's it suppose to be? Doesn't seem like what's there is what is intended.
Jeanne: <looks for definition of process>
Jeanne: In WCAG 3 process is defined as <reads>
<jeanne2> https://
Jeanne: <provides link to definition>
<jeanne2> A sequence of steps that need to be completed in order to accomplish an activity / task from end-to-end.
Jeanne: Rachael was key in crafting this. Not on call.
… Sheri not on call as well.
Jeanne: Sheri would be good for specifics on flashing.
<mbgower> WCAG: process series of user actions where each action is required in order to complete an activity
Shadi: In WCAG 2 definition is mostly used for "all pages part of the process". I don't think it uses the process in absence, which is why it could be an incomplete definition. Related to pages in a process.
<JF> +1 to Shadi - it suggests 'multi-step'
Shadi: Talks about all pages in a process. Using just that part of term w/o context could be problematic.
<JF> Product?
Jeanne: I think what it's talking about... that the order of the page or the tester evaluating the conformance for a product would identify the task that is being accomplished in the view.
<anne_thyme> I will have to jump off. See you next week.
Jeanne: It would be tested... you would run your automated tests, and generic manual tests, and decide purpose of this view and decide purpose user is trying to accomplish. And decide if the error blocks the user from completing the main purpose.
Jeanne: I wanted to call them screens and tasks, but I understand the reason for changing the names.
<JF> How does a tester know what any individual user came to a screen for?
<JF> Presumes each page has a "main purpose"
Jeanne: We could look at it as... you are testing a screen, it has a purpose, there's a process, does any accessibility issue on the page prevent accomplishing what the user is trying to do?
<JustineP> Is that a very subjective assessment in terms of determining what a user can/can't do?
Wilco: My understanding is that this new definition of process was to allow for task based testing. Shawn has been pitching.
Wilco: In which anything you want to define as a task can be tested. But in doing this we created a definition that can potentially cover everything.
<JF> +1 Wilco - clicking a link is a process
Wilco: Seem then that it can't be defined as a critical error. Any error could be called critical.
Wilco: What is a critical error changes on the approach. Hoping Shawn would jump in.
MG: Maybe a key part is the process is defined by the author. If that might help us have the scope defined.
MG: Isn't that a key part of how Silver testing will occur?
Wilco: Then is the author always involved?
<bruce_bailey> @MG: site owner, not author maybe
<Lauriat> No, I can include more on that in my response.
Jeanne: As a general view, the person or group of people who are making a conformance claim would say "this is the process". It's whoever is making the conformance claim.
<mbgower> sure, owner
<JustineP> User needs can be so varied particularly from a cognitive accessibility standpoint.
JF: Struggling with the requirement of being a mind reader. I go to a menu and click on contact. What am I looking for? Any one of the examples could be a process. I don't know why you clicked on contact tab in the first place.
Jeanne: Presumed that tester would have instructions. They are telling you what the process is and what the steps are.
<mbgower> That's why the owner has to define the processes to test, IMO. And the process having been established by the owner, it is then repeatable.
JF: I don't know if that's true. Trying to anticipate needs w/o defining a process. If I create a contact page, there are things I will provide. I will give you a form so you can contact me that way.
JF: Many ways to contact, choose which one meets your need. The process is "get in touch with client".
JF: We talked about needs for definitions. We have very broad definitions that don't hold up to strict scrutiny. I'm struggling.
Jeanne: It would be helpful to provide a proposal. We can't move forward w/o proposals.
Shawn: Answering question of what the processes are there for and how they work. I can speak to who defines them.
Shawn: Wilco you are right, I spoke in terms of tasks, but processes are generic. Exist to build up a way of declaring scope of conformance.
Shawn: It is also the context for deciding if something is a critical error. There may be one error that is a critical error for one process, but not applicable to another.
Shawn: Or could be not critical for a process. a poor label, but the path forward is easily found. But in another, this is THE label required to finish the task. Did that help?
Wilco: It does, but it raises another thing. How does that work with testing views?
<JF> Exactly what I am worried about Wilco
Wilco: If testing a view, you don't need a process. Sounds like you need a process to identify a critical error.
Shawn: Critical for understanding that view and moving on to the next view. I've tried to focus on users trying to do something, even if that something is just to read a page.
Shawn: Or John's example, an online toy that changes colors and does abstract art. There is nothing accomplished other than getting enjoyment.
<Zakim> Lauriat, you wanted to say that processes can build up scope of conformance for communicating the state of the overall thing, so critical specifically in the context of the process under test
Shawn: Approaching always from "can user do this thing", even if thing is simple or complex.
Shawn: Speaking to Mike's comment. We have spent a lot of time coming up with the word, and it's not a perfect word. We appreciate any proposals offline.
Wilco: Sounds like if you always need a process defined, we may want to document that better. Independent testing, is that possible with WCAG 3?
Shawn: Absolutely. If someone is making a conformance claim for their thing, they are declaring the processes and ...
Shawn: Declaring level. ...adds structure to the comparison. Comparison at lower level, element by element.
<mbgower> +1 to what Shawn is saying
<Zakim> alastairc, you wanted to say that it only matter for a conformance claim, if you are a user you go by the guideline and page.
Shawn: Forms it into "I can't do this because I hit this thing".
Alastair: Currently people can pick pages in WCAG 2. Like with WCAG 2 organizations can choose their own. If they choose silly tasks processes that would be obvious.
Alastair: Regulators are stating what must be included in conformance claims. Will play out similar for WCAG 3.
Shadi: Not sure I agree that it's that straight forward. For external bodies like govt bodies to decide what processes or tasks website owner declared are actually sufficient.
<CarlosD> +1 to shadi
<Wilco> +1
<Lauriat> We do need to validate these things, definitely!
Shadi: I'm thinking of an app, you could list quite a bunch, exhaustive list. Not sure if example of pages. Key pages, I think that they are often... in web applications...
<JF> +1 Shadi
Shadi: List of processes and tasks becomes so vast that... I hate it as a wheel chair user to be told to not use a route.
Shadi: This is ringing bells of what "I decided for you to use", rather than providing the services that are being provided for everyone.
<Jennifer_strickland_> +1 to Shadi's expression!
mg: I like the idea of author/owner defining is most of the time, when doing testing, you do this. You can't test everything, and you define important processes, and concentrate testing on that.
mg: This has the potential to make it more transparent.
<jeanne2> +1 to Mgower
<alastairc> True, but procurement processes for complex apps usually define tasks as well, from the client point of view. And providers will define their own that should meet the user-needs. Never going to be perfect, but it builds on what happens already.
mg: To shadi's point, makes it easier to challenge what's been tested. More reproducible test result, and easier to challenge incomplete testing.
<Zakim> JF, you wanted to ask about processes and user-stories
<Lauriat> +1 to Mgower, exactly.
jf: Something Shadi said, for me when I think of processes, I think of user stories. "As a user of screen reader..." "as a user of limited mobility..." There's test for one process. They may not have the same outcomes.
jf: The moment we try to define user paths, we are opening up a world of hurt. We just don't know.
jf: Jamie Knight, understanding a user with autism. We need to factor in all the disability types. It is going to have to define multiple tests.
<Zakim> Wilco, you wanted to propose we park this
Wilco: I want to suggest... this is an important topic. More needs to be said. Jeanne, can we have a separate point to have this conversation? This is not an ACT topic, beyond we need good defiitions.
Wilco: Can we postpone?
Jeanne: That's a good approach.
<jeanne2> question+ How do we define process - this should be discussed with AGWG
<Lauriat> +1 to Wilco, I think we wanted to walk through examples, which would help us in that conversation in the first place.
Wilco: I want to get through critical errors portion of survey.
<JF> My proposal is to have a much clearer and accountable definition of "process"
Shadi: I agree with you Wilco. I think we have it on record, I disagree with the idea that it would make it more transparent. I think it might make it less.
<JF> +1 Shadi - less transparent and far more complex
<Zakim> bruce_bailey, you wanted to ask if we expect WCAG3 to require posting of conformance claims?
Shadi: I think that there will be claims of conformance, but would have to read fine print.
Bruce: With Mike's point about making it easier to challenge what's been tested. Do we expect WCAG 3 to make publicly available conformance claims?
Bruce: A neutral 3rd party will have no idea what that is.
Jeanne: We have never discussed having publicly available conformance claims.
Wilco: Can Jeanne take us back to critical errors? I want to save last 10 minutes to discuss plans for next week.
<mbgower> I agree with Bruce, that that must be in there.
Jeanne: This is all good discussion. I hoped to get into methods and tests.
Wilco: <screen sharing>
Wilco: Let's try to get through critical errors.
Wilco: Leave scoring separately. My comment on critical errors are largely discussed at this point.
Wilco: ,,,very subjective...
Aron: That's regarding the rating scale. Looks like 25% or less... not really about outcomes. Not critical errors related.
Aron: I wasn't able to tie outcomes to scale. I wasn't sure what a critical error was. My view on outcome is same as yours. I don't know what constitutes a necessary heading.
Aron: If there is an instruction to compete a task, that mentions the heading, then it needs to be visually distinct and programatically determinable. That's the only case I thought would be critical.
Wilco: I left similar comment, and similar comment from Anne. There are some struggles here. Even if we know what a process is.
<Jennifer_strickland_> Those are comments noted in the Github Issues from respondents, as well, that have not yet been incorporated.
<JF> Critical error also tracks back to which user-story?
Jeanne: Part of what the groups contended with, very little time. We didn't discuss weaknesses of what was defined.
JF: Critical error tracks back to user story.
Jeanne: Closely tracks to tasks, disability neutral.
<JF> except outcomes are not disability neutral - different disabilities have different types of "critical errors"
mg: In regards to critical error for heading, I'm struggling to define minimum or maximum content requiring a heading. It's difficult to make something testible.
<JustineP> +1 JF and Mike those are my concerns as well
mg: If you think it's a comment by user. I'm trying to imagine any kind of measurement that would say "this needs a heading, this doesn't need a heading".
Wilco: Wondering if we need critical errors for this outcome.
Jeanne: Queued myself to echo same comment.
<Zakim> Lauriat, you wanted to offer a possible example of a critical heading error
Shawn: I was going to say same thing, not everything will have a critical error. Flip is true. For example of something with headings...
Shawn: Have a complex document or U/I, 150 H1's that have same text in them. It's arbitrary, criticality is debatable.
Shawn: Imaginative. My way of +1 Jeanne's and Mikes point.
<jeanne2> One or more headings necessary to locate the content needed to complete a process are not coded as headings.
Jeanne: Critical error for another outcome, conveys hierarchy, critical error there is that one or more headings are not coded as headings May be a better example of a critical error.
Wilco: We are getting close to end of meeting.
Wilco: HOw ACT format can be blended with methods. Let's see how much we can get done on this survey.
Wilco: Maybe add one more question for next meeting.
Jeanne: We may not want to do a survey like this. Inspired engagement, but maybe not productive to have gone through answers the way we did. I'm hoping to get questions that get us in the direction we want to go.
Jeanne: It's huge that we needed definitions and not rules at the outcome level. That's a big step forward. We spend a lot of time on other topics and not that.
Wilco: Others?
<Chuck_> Jennifer: Any sessions needs opportunity for related sub group to review comments before proceeding, so we can be more helpful and aid the colaborative proess.
<Chuck_> Jeanne: I agree, but sometimes survey is filled out at very start of call.
<Chuck_> Jennifer: I have similar challenges.
<Chuck_> Jeanne: I suggest in next session we take example of methods, and look at how the ACT rules apply, and how we can better communicate the ACT rules.
<Chuck_> Jeanne: For the people who will be doing the testing and implementing.
<Chuck_> Jeanne: I would like to have next session be about ACT rules and where they sit. And if anything needs to change.
<Chuck_> Wilco: Not perfectly aligned, but close. We do need some tough conversations about which way to go in some instances.
<Chuck_> Jeanne: WCAG 3 is in dough and not baked stage, we have flexibility.
<bruce_bailey> +1 for sharing act rules
<Chuck_> Wilco: Share some rules ahead of next meeting? Give people a chance to review, as prep?
<CarlosD> +1
<Francis_Storr> +1
<Chuck_> Jeanne: I like that, especially ones related to headings.
<Chuck_> someone: Headings or structured content?
<Chuck_> Wilco: Landmarks might be, we have one or two.
<Chuck_> someone: We have bypass blocks.
<Chuck_> Shadi: And lists.
Jeanne: We'll send out new homework, reviewing ACT tests. Next call is next Friday, same time, same channel.
… We will focus on how ACT rules fit with the methods.
… Thank you all for joining