See also: IRC log
Wilco: No comments made in the survey, approved.
wilco: Fully agree with Moe's comments.
Moe: There is a "review changes" button
available to us, but not sure it is available to those with reader or
contributor level rather than editor level.
... Both methods of making comments show up in the conversation threads
for the pull request.
maryjom: There are multiple ways to provide comments - either on the conversation, using the review changes, and by adding comments by using the "+" in the file content itself to put comments right in the file
wilco: Don't want to overcomplicate it.
All methods of commenting are fine.
... You can provide a pull request on another pull request.
moe: Do you want me to do that and update the pull request?
wilco: Let's merge this pull request and then create another pull request with the changes.
Alistair: Having trouble with github.
Couldn't find the text to review.
... Github is difficult, and doesn't like using it to create documents.
Better suited for developing code and this isn't code.
... We don't utilize emails enough. This method of contribution is
complicated.
wilco: What can we do to accommodate?
Alistair: I will read the github manual to see if that helps.
Moe: As a new user of github it was
confusing, but the more I use it the more helpful I find it.
... A year ago someone from the WCAG working group did a 1 hour demo
which was very helpful.
... Things get lost in my email inbox, so having a repository that
focuses on the work being done.
wilco: There are a subset of functions you'll need to use in github - not everything in the manual. Shadi and Wilco can help people get on board with github.
Charu: Someone helped me learn how to create branches, etc. and that was helpful.
Wilco: I'll work on this to help people in the ACT TF and the auto-wcag group. I'll put this at the top of my to-do list.
wilco: Agree with Shadi's comments.
... Discussion on staged testing. Black box and white box testing aren't
really two stages, but more categories of testing.
charu: Black box and white box testing is new to me but I realize some teams do that. The pre-processing is the difference between them. One stage is before the content is rendered, and the other is the rendered content.
Alistair: Black box and white box testing as described here is quite different than what it means in software testing. If you're a software tester it isn't really the same as pre-rendering and post-rendering.
wilco: Usually we test the end results - the UI as it is presented, which I consider black box testing. White box testing is when you're testing the source code, like linting, where you look at source files and not the rendering.
Alistair: Testing something like Windows OS, you're testing the UI and it is black box testing.
Wilco: It is a new use of the term "white
box" testing.
... Maybe those terms are too confusing. Given the response on the
survey something different might be necessary.
Moe: You are looking at rendered HTML. As a functional tester you don't get into the code - you're looking at the functionality.
Wilco: Whatever the DOM is made up of, that's the black box test. The element in the DOM would be what you test in the black box.
Moe: I see white box testing as testing through the DOM.
Wilco: I understand the confusion.
Charu: Once the DOM is formed, the browser has done the pre-processing.
Moe: I see tools that test using the DOM do have access to the internal structure. What I see as black box testing is the actual interaction with what's rendered on the screen.
Charu: I like Alistair's suggestion as "rendered" and "pre-rendered"
Wilco: Maybe "processed" and "pre-processed" is better.
Charu: IBM rules are meant to be used on the rendered content.
Wilco: Facebook has a tool that looks at the react code.
Charu: True, a lot of dynamic content is not available without looking at the actual code.
Wilco: We don't want to exclude either method of testing - code or DOM content.
Alistair: It all depends on what you
consider "processed" vs. "pre-processed"
... We have lots of tools that look at different DOM states - just
having one DOM state doesn't really work. When you use tools, it looks
at DOM state zero, and as the DOM state changes there may be changes
made that make the content inaccessible.
... It highlights one issue to do with this process. It may not be easy
to keep this future-proofed. We don't know what's going to happen next
year. If we only focus on what is there today, the ACT rules could be
obsolete in the future.
... One thing to focus on is to combine our unit test suites and less
focus on how we create the tests.
... I suggest 'source file testing.'
Wilco: I agree with Alistair's
suggestion.
... Will update due to comments and we'll have another pass at it when
it is ready.
Wilco: I expected more feedback on
accessibility support than I got. Editorial comments from Mary Jo.
... We should move this discussion to next meeting when we have
Alistair's comments.
... Alistair, have you looked at accessibility support previously?
Alistair: We haven't gotten to the point
of saying to use one test vs. another due to issues in accessibility
support.
... I'm more interested on customers using best practices that are more
automatically testable which makes the test for compliance easier.
Wilco: I've seen a lot of of accessibility support issues.
Alistair: You don't want to create a maintenance nightmare.
Wilco: You want to produce valid results.
Alistair: There are no standards for the additional semantics that a screen reader provides. Example, one screen reader beeps on links where another announces 'link'.
Wilco: Seems like you don't want to tackle accessibility support in this spec, but I want to have a reasonable mention of this.
Alistair: I'm worried about future-proofing our tests. Would like to focus on unit test now. There will be computer learning methods of test in the future that likely won't comply with ACT. So suggest accessibility support is treated real lightly and not too prescriptive.
Wilco: My section 6.1 is ready for survey
for next week.
... Others are not done yet but will be soon.
Charu: Pull request 42 is ready for survey.
Mary Jo: I'm not sure exactly what goes in my assigned section. Will email Wilco on that to get some help understanding.
Moe: I went to auto-wcag for inspiration
on my assigned section - Rule Outline. I don't want to get too
prescriptive, and wondered if you want details or an outline of what
each section means?
... We chould call out pass/fail outcomes as part of the outline. It is
a bit more challenging than anticipated, but will keep working on it.
Alistair: 6.2 Pulling Results Together -
Haven't gotton to that quite yet.
... If there's additional documentation on how we might put together
various peoples test - benchmarking, I have some ideas for that section.
Wilco: Yes, you can put down ideas so we go over it.
Charu: Still have 7.1 - Manage exceptions to work on
Wilco: Ran out of time, will discuss next week.