See also: IRC log
wilco: 2 comments
... 1. a broken link
... may be not worth the trouble to fix it
... 2. a comment from Mary Jo
shadi: just send me offline what needs to be fixed
wilco: Romain wrote a proposal for the Selectors section
https://github.com/w3c/wcag-act/pull/21
rdeltour: I don't think the language being too technical is much of an issue for a spec? can you elaborate?
wilco: "selectors is a boolean predicate" sounds complicate
<Wilco> https://www.w3.org/2002/09/wbs/93339/ACTTF14Dec2016/results
alistair: going to the text from GitHub is troublesome
wilco: the text is copied in the survey
shadi: you can also use rawgit
rdeltour: I for one pretty much like the github view which shows the diff
alistair: wrt the selector test, it's not
just a boolean predicate
... why don't we just use the text from the W3C spec for CSS selectors
<agarrison> Why not have something like - "selectors are patterns used to select the element(s) you want to work with."
rdeltour: I did adapt the definition in Selectors Level 4, so the definition will change to something like this
<MoeKraft> From Selectors Level 3 Recommendation: Selectors are patterns that match against elements in a tree, and as such form one of several technologies that can be used to select nodes in an XML document. Selectors have been optimized for use with HTML and XML, and are designed to be usable in performance-critical code.
rdeltour: a selector *is* conceptually a boolean predicate
wilco: this is why I suggested to simplify the text
rdeltour: ok
alistair: we have to be careful about elements, I always say "nodes" now
rdeltour: I used "elements" very broadly, not in the markup meaning, but as in "element in a set"
wilco: let's look at shadi's comment
shadi: I think the most important comment
is to take a plainer language
... CSS 3 can be used as an input
<MoeKraft> +1 to simplified text
shadi: not complicate things with 'boolean'
rdeltour: I was trying to use precise language, I find "boolean predicate" was precisely describing what is a "pattern that matches" something, but won't object a change in that direction if people feel more confortable
wilco: in axe we call these things
"matchers"
... selector is a bit too close to CSS, and we look at a couple other
qualities
... not even sure "selector" is the right word
rdeltour: I agree. Selectors is probably too close to CSS and can be confusing. Using a different terminology can avoid the confusion
alistair: what we're looking for is a
candidate set ready to test
... in effect, "select the stuff that you're ready to test"
... as long as we define it as something very general, I think there's
no risk of confusion with CSS
wilco: I see your point
... I kind of like the word "selector", if we can make clear enough that
these things are not necessarily CSS selectors
... let's see if we can come up with a text
<MoeKraft> it's a selector :)
<agarrison> function that allows you to collect content to test
rdeltour: I think we want to keep the concept of "filtering"
alistair: we use applicability conditions
before we go ahead and run the tests
... we could have something very light, "function that allows you to
collect content to test"
wilco: it's not necessarily programatic
alistair: it has a broader context than just programming
<MoeKraft> From AXE: "Upon execution, a Rule runs each of its Checks against all relevant nodes. Which nodes are relevant is determined by the Rule's selector property and matches function. If a Rule has no Checks that apply to a given node, the Rule will result in an inapplicable result."
rdletour: I found defining "selectors" was
difficult without knowing the definition of "input data", since
selectors are applied to input data
... maybe we should look at that first
<Wilco> A selector is a procedure for locating elements or components within the test subject that are to be tested using the rule.
alistair: what do you have in mind? input data is essentially the DOM
wilco: not only (...)
moe: I don't want to be too generic
charu: I agree that dev are mostly familiar to selector terminology. As long as we describe it for the general public and keep selectors it can work
wilco: I want to pass it on, maybe Moe you can try to humanize this description a little bit?
rdeltour: don't hesitate to ask if you need help!
wilco: I think we can elaborate a bit on the proposed list
<MoeKraft> https://github.com/w3c/wcag-act/pull/12
wilco: I think we need more explanation on "limitations and assumptions", we need to clarify that
charu: I put that over there because when we are actually writing the rules we do have assumptions and limitations based on the requirements
<Wilco> https://auto-wcag.github.io/auto-wcag/pages/design/rule-design.html#assumptions
wilco: the link above is what we said in Auto-WCAG
charu: it looks like we have a whole new section for "Assumptions"
wilco: if it's clear to people what is
meant by assumption in this context...
... if we don't clarify this section and leave it as-is, is it gonna be
alright?
rdeltour: I think it can be solved by putting a couple examples of assumption and limitations
charu: good idea, I can put some examples
wilco: cool, sounds good.
<MoeKraft> https://github.com/w3c/wcag-act/pull/20
wilco: for english speaker, do you think this text is clear enough?
moe: transparency was one of the words we
brought up in a call 2 weeks ago
... I guess the best way to describe it is that it's clear, it's clearly
understandable
wilco: what I meant with "transparency" is
that anyone could see through it, in terms of openness, there's no black
box approach to this
... in closed sw, you throw some input, get results, and don't know how
... I think "transparency" means you know why you get the results you
get
... is that different from the way you see it Moe?
moe: no, not really
rdeltour: I thought "transparency" here was a bit misplaced, or at least if we want to make it a strong point we should elaborate and explain it further
charu: I think I agree (...)
... I agree with Wilco's interpretaiton
... what we mean is more "harmonized" or "standardized" set of test
methods
<MoeKraft> From wikipedia, "White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing). In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases."
wilco: ACT is about harmonizing
... but the point of ACT is to standardize how you write rule. the
harmonization comes after that/
rdeltour: it's an introduction, so we can be a bit more verbose. I'd remove "transparent" here and add a setence to explain the concept of transparency
moe: in the introduction or somewhere else?
rdeltour: I'd say in the introduction
moe: for the process, should we accept the PR and make the transparency in another PR?
wilco: yes
alistair: is the document being built out
somewhere in a complete document? can we have that for meetings?
... in my mind it's hard to look at PR, all I want to see is the text
... if you want to show comments, that's fine. but can we have the link
to the built-out document too?
rdeltour: we don't have the built-out document for the new proposal, just for what has been accepted so far
alistair: that's fine, at least we can
comment on the agreed document
... we only have an hour to put to this, and we need something as clear
as possible, even if it means someone dumping something in IRC
maryjom: the survey has the updated text, I scraped it out
<cpandhi> Link:
<cpandhi> https://www.w3.org/2002/09/wbs/93339/ACTTF14Dec2016/
maryjom: you should look at the survey, it has links to issues or whatever
<shadi> +1 to use github comments rather than surveys
rdeltour: while we're at it, I find it
confusing to have both survey comments and gh comments, can lead to
duplication
... I'd suggest to use gh only just because it's less rigid than the
survey mecanism
wilco: we need to make a recommendation,
yes
... alistair, wdyt?
alistair: if we can just have the complete document...
<Wilco> https://w3c.github.io/wcag-act/act-framework.html
wilco: I can make sure that every week we have what's currently accepted on this URL
alistair: that would be perfect
rdeltour: can we add an "I don't know" option to the survey?
shadi: to share experience from other
groups...
... romain's concern can be obtained by rephrasing the option
+1 for "needs more work"
scribe: you can generate HTML or a document
for a PR
... you can also use the HTML diff service to show the changes
... I can work with you offline to generate such URLs
... will make easier for people to review these proposal
... on the workflow, I think it'd make sense to have the survey a week
ahead, rather than have really fresh comments
... so editors can bring questions they have in the following week
... there's time to consider the questions by the whole group before
closing the survey
wilco: I'd also suggest that the survey gets closed at least one day in advance
shadi: could be, or it could be in
parallel: have a survey opened for the next week
... different ways to handle that, but we need to give more time to
consider the comments before the group
wilco: OK. let's see if we can start doing that.
shadi: it depends on the kind of questions
as well
... a review survey may need more time than a weekly survey where people
approve the minutes
rdeltour: can we just use gh for voting on the change proposals?
shadi: some groups work like that, but it
needs more gh activity
... the survey handles people a bit more
wilco: what I'm trying to do is have
surveys on the wednesday after the meeting
... we look at what the results are and decide on the agenda with the
management on tuesdays
... we can put all of the new text in the survey, put the current
version, and then any comment you may have can be left on gh in the PR
itself
rdeltour: OK, sgtm
alistair: ok, sounds good
wilco: we have a plan!
... mary jo's away for the next week
... thank you everyone!