WF: promised a survey last week
... but after auto-WCAG discussion, identified several issues
... problem with applicability and expectations is that could equally
well apply to entire success criteria
... not specific enough to write test rules
... need to ensure we can break up the things in smaller pieces
... selectors and tests helped us with that, but too limiting
... for example, "applicability: non-text content" and "expectation:
text alternative serving equivalent purpose ..."
<Wilco> https://github.com/w3c/wcag-act/pull/155/files?diff=split#diff-9ac0a6633720a5535b0a53cba04ababeR150
WF: does not really break down the problem
... introducing the idea of being unambiguous
... but need more input on how we can be more specific while using the
applicability/expectation approach
Kasper: definitely agree with the potential
of misuse
... like the idea of "unambiguous"
Wilco: what about expectations not having
that same requirement?
... example "is the text alternative descriptive of the image" cannot be
unambiguous
Kapser: difference between being ambiguous
and subjective
... for example "descriptive" is subjective but not necessarily
ambiguous
Anne: maybe need more guidance
... "descriptive" is somewhat ambiguous
... maybe also for expectations
Romain: seems to me that the ambiguity
depends on the actual test
... some are by nature more objective than others
... maybe need some wording or label or such to declare the subjectivity
of tests
Shadi: think also applies to applicability
... think that "non-text content" is unambiguous
... but not specific
... agree, depends on nature of test
... but seems we want to nail down specifity
Wilco: for me, the "content" is ambiguous
... need to narrow down the exact scope
<Wilco> An unambiguous description is one that can be resolved without uncertainty in a given technology. Examples of unambiguous properties in HTML are element names, their computed role, the spacing between two elements, etc. Ambiguous properties are concepts like decorative, navigation mechanism and pre-recorded. Even concepts like headings and images can be misunderstood. Is this talking about the tag name, the accessibility role, it's purpose in the web page? [CUT]
<Wilco> The later of which is almost impossible to define with no ambiguity. When used in applicability, these concepts MUST have an unambiguous definition.
Shadi: agree - need to define what test rule authors need to do in order to be "unambiguous" or "specific" or whatever other attributes
Wilco: points out definition
Shadi: looks good. but also need to be more
specific for expectation
... for example "good text alternative" is too vague
<Wilco> Each rule MUST contain one or more expectations. An expectation is a statement that must be true about each test target (see Applicability). Each expectation MUST be written in plain language. Unlike in applicability, a certain level of ambiguity is allowed in expectations
Wilco: could we say something like "expectations should not rely on subjective statements, like good or bad"?
Kasper: think "good" is more ambiguous than
"subjective"
... but would be good to add something like that
Shadi: is the guidance on how atomic also
useful in this context?
... to help breakdown requirements?
Wilco: not sure right approach for every
type of test
... for example, "check every role has appropriate attribute"
... having to break that down for each type of role would be unnecessary
... no general rule on atomic, needs to be looked at for every rule
<rdeltour> +1 on applicability being more strict than expectations
Kasper: not sure we need some level of ambiguity for expectations, but some level of subjectivity
Wilco: how to differentiate?
<anne_thyme> Example of subjective expectations that are not ambigious: https://uu.difi.no/om-oss/english/indicators-universal-design-web-solutions/key-indicators
Anne: Difi indicators from Norway
... for example "does the text convery the same information in the
image"
... this is umabiguous but to a certain degree subjective
Wilco: so actually stating the exact property
Anne: yes, i guess. trying to address people new to accessibility
Moe: agree with Anne
... subjective is when you need human interaction to determine outcome
... but ambiguous is something that is not well-defined
... not specific to the evaluator
... ambiguous relates to confusing
<MoeKraft> Subjective: 1.existing in the mind; belonging to the thinking subject rather than to the object of thought (opposed to objective ). 2. pertaining to or characteristic of an individual; personal; individual: a subjective evaluation. 3.placing excessive emphasis on one's own moods, attitudes, opinions, etc.; unduly egocentric.
Wilco: so for applicability we want them to
be objective and unambiguous
... and for expectation unambiguous but somewhat more subjective
[agreement]
Wilco: will work on that
<MoeKraft> Ambiguous: 1. open to or having several possible meanings or interpretations; equivocal: 2. of doubtful or uncertain nature; difficult to comprehend, distinguish, or classify: 3. lacking clearness or definiteness; obscure; indistinct:
Kasper: added note on aspects
... on being discrete
Wilco: could accessibility tree be an aspect?
Kasper: absolutely
Wilco: been pondering about which tests go
on the accessibility tree versus DOM tree
... example of where one would need to different aspects
... for example, in WCAG 2.1 there is a new requirement on labels
... requires such comparison between the two trees
Kasper: agree
Wilco: so let's add that in, then
... can you complete this by Monday?
Kasper: yes, I hope by tomorrow
Shadi: sorry, did not get to it this week.
... next week
Wilco: seems good to me
Kasper: yes, me too
Wilco: initially thought R1, R2, etc
... but then tried a rule-group
... and it all went weird
[side discussion on design of the test rules, and if we should continue sticking with the Techniques format]
<Wilco> ACT-R3A
<Wilco> ACT3A
Shadi: are these just handles or also processed somehow?
Wilco: mostly handles
Shadi: does it help to use "R" for rules and "G" for rule groups?
Wilco: rule groups currently do not have identifiers at the moment
Kasper: no strong feeling but fact that rule
groups are not separate entities has me somewhat worried
... they are defined within the rules rather than as individual entities
... makes it less usable
... have to use it from rules rather than the other way around?
Wilco: good point, need to define rule
groups on their own?
... will propose something
Wilco: have several open issues, many reviewed but need resolving
[looking on issues]
Wilco: please resolve by Monday