<alastairc> WCAG 2.x issue resolutions (Q1-6) https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/

<ChrisLoiselle> scribe:ChrisLoiselle

<scribe> scribe: ChrisLoiselle

<AWK> +AWK

<AWK> trackbot, draft minutes

WCAG 3.0 Headings review https://www.w3.org/2002/09/wbs/35422/wcag3-method-headings-exercise/

<Chuck> https://www.w3.org/2002/09/wbs/35422/wcag3-method-headings-exercise/results

AlastairC: First hour will be headings review around WCAG 3.0 , shares screen.
... top to bottom approach on structure content guideline
... responders comments on headings method and test review are provided in results url https://www.w3.org/2002/09/wbs/35422/wcag3-method-headings-exercise/results
... if there are things that are wider than headings, i.e. across the wcag 3.0 structure, feel free to comment where applicable.
... Justine P. talks to short pages not being divided into separate sections. Raises question on the if appropriate phrasing Justine raised in her comment.

Jeanne: On topic of if appropriate text phrasing, we are looking to be unambiguous as possible

AlastairC: opens to Justine

Justine: I don't have a strong preference on the phrasing of if appropriate , just wanted to raise the issue in general.

AlastairC: Point taken.
... AWK talked to normative language around outcome, i.e. what is the outcome, what is the normative part we need to deal with? It is helpful to have link to outcome, but it wasn't worded the same. Perhaps an artifact of the production process of wcag 3. May raise in future unless we look into this now.
... Talks to CMS for WCAG 2. and possibly WCAG 3 and an include catching mechanism to align documents properly.

Jake: People have different interpretations of what a heading is, i.e. h1, aria heading, nested list with bold text, fieldset and legend , heading in a structure, landmarks, etc. What is the normative part regarding part of navigation or part of structure ? Legends , captions, might look like a heading...

<JF> Test Procedure for sections with headings • Check that the content is divided into separate sections. • Check that each section on the page starts with a heading.

<JF> • What or who determines if content is ‘properly sectioned’? • Do all <divs> (a sectioning element) require a heading? • Does every html document require at least 1 heading (<h1>)?

Jake: if we don't tackle this specific area, may cause confusion. ACT talks to a coded heading, i.e. heading or aria level heading and not other related heading type content and elements.

AlastairC: Other elements may have similar visual representation, but are not required within a coding practice.

Jake: It makes measuring the headings difficult , as you rely on different perspectives.
... ACT talks to role of heading within Accessibility API and go from there.

<Zakim> jeanne, you wanted to answer Jake

AlastairC: Covers the testing of those elements, but doesn't go into the particulars of making headings accessible , have to look at both sides.

Jenny: Talks to multiple syllables per word and people that are trying to parse , which goes into understandability and readability

Jeanne: I agree with Jake. The work we did on Friday will help us in this area.
... stakeholders are clear on what they are looking for in terms of headings. We also have tool makers, on what specific definition is of heading. We are going to keep plain language part
... excluding and including of what detail section explains the edge cases.
... We do need to do a lot of plain language work.

AlastairC: Do we look at what we have and if headings are missing, do we take that from a visual basis or a structure basis. I don't think that is clear at moment.
... On AWK's comment on headings, talks to PDFs and heading at top of document. Structure around landmarks.
... talks to possibility of headings and sections and moves forward on AWK's scoring example and logistics.
... If we have a shorter page, one heading may drop your rating . Subjectivity and overall effort to evaluate may be burdensome.

Scoring and difficulty

AWK: Talks to section headings, at AAA , parallel semantic structure to the visual structure. Talks to counting headings and how many should be there , calculating this, and then managing it. Do we have enough research to say in the WCAG spec, if there were 20 less headings, the user would not be able to use the spec?
... We need to be able to back this up with data and why this must be done.

<Wilco> +1

<johnkirkwood> +1

<Zakim> Chuck, you wanted to make observation about the "workload"

Chuck: On the effort WCAG 2.x and 3.0 was not much different on effort. To me , it was up to , but not including the counting aspect.
... does tooling help with the counting?

<Zakim> AWK, you wanted to respond to chuck

<jon_avila> I agree with Chuck that today we already have to look at each heading and look at each piece of text that looks like a heading but isn't.

<JF> +1 to AWK

<johnkirkwood> +1

<Zakim> JF, you wanted to ask if there is such a thing as too many headings in a document?

AWK: I think the difference I came across , WCAG 2.0, or 1, we are saying that looks like a heading, then is the heading structure behind it saying that as well. On 3.0, we need to confirm the should be but and then to the evaluation. The work needed would be to understand the content and then apply the analysis of Bolding does apply and sections that content area.

<jon_avila> We already today have to fail things that look like headings but aren't and for level AAA we already have to look for sections that may be missing headings.

<alastairc> just few people (regularly) do AAA testing

JF: Is there such a thing as too many headings on a page? Adding or removing a heading may manipulate a score. Adding and dividing , are we using page as unit of measurement? concern around number , quantity is concerning on final score.

<Zakim> jeanne, you wanted to talk about the levels use cases

<AWK> agreed with jon_avila and alastair

<jon_avila> Today we already have a quantity - if you have 1 failure you fail and your page is considered not accessible to people with disabilities

Jeanne: To AWK, on levels and use cases ... do you think we need to link to research ?

<alastairc> Research for this: Webaim survey that shows headings are a primarily nav method, not sure there is more.

<david-macdonald> Use the resources section of the understanding doc to document outside research to back up our claims

AWK: It is not needed all the time . I.e. ten years down the road, it may not be entirely beneficial but could be useful.

Jeanne: Requirement around levels topic, the more we found use cases where it was difficult to say you have to follow a heading structure. I.e. large corporate home pages , news from this department, for example. That department had different heading structure on that page.
... I'm not sure where we should go with that .

<Zakim> Wilco, you wanted to task for test cases

Jeanne: AG's recommendation on levels is welcome.

Wilco: We built up big lists in ACT on edge cases , then explaining the result helps frame the conversation and check assumptions on it . If we adopt this from an AG or AG and Silver , it would be beneficial on testing against criteria.

<JF> +1 to Jon

<Wilco> +1, missing the h1 is a much bigger problem then missing any of a dozen h4s

JonA: A website has an issue like this now, it is a failure per ADA. Generally , people are doing this today , at a adhoc basis. We do need a framework of what is this level of accessibility. I don't think it is a percentage only, it is contextual. Take accessibility or inaccessibility of page, then take the relationship of content against other content. I.e. human perceives vs. what the code is per a machine readable testing.

AlastairC: Machine based, but not based solely on percentage.

Jake: JF talked to various pages as a use case around headings. They looked the same, but they had different issues. It was a very valuable exercise. They should provide different measuring results and should be used to talk about this subject. Completely different structure of headings and a starting point.

<jeanne> +1 to Jake and JF's collection of use cases.

Wilco: We need a structural way of methodically going through this. Doing this in a test driven way, we need lots of test cases.

AlastairC: A database would be worthwhile , perhaps starting with a wiki.

<Zakim> Chuck, you wanted to ask if we ever received a scoring spreadsheet on JF's example page.

Chuck: Talks to the Scoring spreadsheet of JF's example.
... did we ever get the scoring data ?

AlastairC: Testing may be out dated at this point if we did.

DavidMcD: Talks to visual ways of evaluating , i.e. did author intend it to be a heading, i.e. bold, large font, spacing , positioning, length of string, capitalization.

<JF> Jake referenced these tests: https://john.foliot.ca/demos/HeadingsTestStart.html

The second issue is critical error , does it say mailing address, but not visually distinct ? (different outcome than the first, but still part of the heading guideline)

scribe: heading should be there, but isn't , is that a critical error?
... third issue is around rating scale, there are 5 different types of things to count and then calculate the percentages . Counting up passes may not improve accessibility and adds to audit costs. Manual evaluators shouldn't be documenting correctly implemented accessibility. They should be analyzing and reporting on errors and how to improve.
... issue 4, talks to new failure in informative, non normative text. Is 2.4.6 morphing into WCAG 3 ? The normative text should reflect the requirement.
... I've seen lawsuits where skipped headings , h1 followed by h4 etc. I do think we need say something about it, but not sure where to state it.

hope I got that all !

<JF> That was the idea that drove the obsoleted Section Headings algorithm in HTML5

Chuck: I want to thank DavidMcD's comments on counting the successes as well as the failures, thank you for discussing and raising.

<Zakim> JF, you wanted to ask about "sections"

JF: In test example, talks to content is in separate sections and is a heading. How does that relate to ePUB ? I.e. every page in a document need to have a heading? A page may have a whole bunch of paragraphs . Seems to be HTML specific write up on guideline . What do we mean by a section? AWK mentioned Landmarks.
... we can have a rule that talks to landmarks. A div is also a sectioning element , do all divs have to have a heading? Clearer definition on what is a section.

<JF> I agree Jake

Jake: to JF, landmarks by a region, ...
... On counting up headings, on the 'load more' type pages, when does the page end ? When do you stop counting ?
... There are different variations , what does the automated test need to do to count? There are not just edge cases, but expanding edge cases to consider. Definition of view.

Bruce: I think I'm not adding anything additional to what was previously mentioned to date here. Outcomes not being statements? We can come back to that later , nothing additional at moment.

AlastairC: semantic structure on different technologies was Jennifer S.'s comment. Did I capture this Jennifer? Jennifer not on call.
... Laura Carlson asks questions around percentage and measurement aspect ?
... If you get a heading level 2 wrong, then other headings underneath that are also wrong. How is that measured ? Cascading error.

<jeanne> +1 to Alastair, that was one of the use cases of why we dropped it, even though all the supporting material didn't get deleted.

AlastairC: Text headings vs. non text headings that doesn't need a text alternative.

Jeanne: It definitely needs more work and wasn't remove at time of publication .

AlastairC: on Laura's comment, what is a heading? Yes, great to have a definition.
... Shares a document guideline, outcome tests that he used as a draft . He agreed with AWK's comments.
... thought the user requirement was the main goal and then go into specifics.

Jeanne: I don't think we tried to implement that into the guideline. Writing the guideline was the last step in our process.

<JakeAbma> +1 Alastair, there probvably is one of the solutions...

Jeanne: Guidelines need to be more aligned with user needs .

AlastairC: Outcome could talk to users are able to navigate structure, then talk to requirements around that.

<Jaunita_George> +1 to Alastair's comment about separating the SC

<Jaunita_George> Or tests

AlastairC: heading failure if headings aren't marked up as such. The "has headings" vs. the "levels" aspect. I'm not against the heading levels aspect, I think it could be done a bit differently. I.e. using heading markup to identify headings. Then talks to procedure (for each test) then heading levels to structure page. Then talks to procedure for each test, does that heading showcase as lower , i.e. is it a sub heading or is it new?
... then I went into the ratings for headings , around organize content . Main goal is having headings. Then adding in that they have the appropriate level. Currently, all are bundled in together. Separation would be better and then building up.

<Ben> +1 to AC

sure, that would be amazing !

<Rain> scribe: Rain

<ChrisLoiselle> thank you!

alastairc: I will often run an exercise and get people to mark up the page, and they will come up with better subsections because they understand the content better
... that is an alarm bell as to how this is assessed, because it may not be unambiguous
... looking at Stephan's comment, not sure on the specifics but thinking he would like some examples. This is something that might go into a lower level document
... Looking at Aimee's comments (not on call). Not sure what means by platform section. Not sure if relevant to today's exercise.

<Zakim> jeanne, you wanted to answer for Aimee

jeanne: responding to Aimee's first point. In the method, the first page talks about what platform it applies to and what technology.
... I think that's an area that we need to make the methods much more granular as far as the technology.
... In this case what we meant, as far as I know, trying to say that this one applies only to HTML, but HTML can apply on a number of different platforms.
... That's another one that we could use help from AGWG.

alastairc: Okay, on test levels, I think we can move past that one.

Makoto: not adding anything at this time today, but making a couple of comments on the tests. Found gray area. Care about measureability and repeatability.
... Please ask me any questions you have.

alastairc: Makoto's comments look like detailed ones that Jeanne will pass on to the subgroup. Moving on to Michael Gower's comment.

mbgower: Looking at structured content vs. visual contrast of text. There is a whole lot that goes into one and not a lot into the other. One is a category, the other is a restraint. The information was not yet properly normalized.
... As such, should only fail one thing in one situation. Structured content is a kitchen sink.
... Some of my other comments are along the same lines. Paragraphs and lists are structured content.
... One exercise to do now: look at the actual results of the survey. It's pretty clear that it is in a grid, but the first column of the grid is the heading. My content is preceeded by the content before it, which is my name.
... I don't think you could have arrived by that with how we have defined things so far. Need to think about what is indicating the structure of the page, as opposed to what is a heading. A cell in a table could actually be labeled as content structure.
... Different languages and different cultures may also have different opinions on how much content needs to have structural labels.

alastairc: Jeanne mentions also that the name headings changed to structured content a while ago, but we don't have enough content on that granularity at the top level yet. Almost the easiest level to work from is the lowest level, from the tests up.
... But it may well be that we need to restructure things at a higher level.
... concluding this section, there are a lot of bits to pass on to the subgroup that is working on this. Are there any comments applicable to the broader guidelines as well?

jeanne: Quite a bit. I have five notes.
... 1. from John Avila about the framework. How to evaluate the accessibility and inaccessibility of the page in relationship to other comment. Touched on it in the ACT meeting. Would like to have a followup conversation offline with John.
... 2. Wilco collection of cases we have done.
... 3. David, if we are going to be counting should be counting errors and not what passes.
... tricky one, but can follow up

4. Alistair following up on looking more closely at use cases

jeanne: 5. renaming of the guidelines and level of the naming
... Would like to ask for a few people from AG who could give us a few weeks to help us fix the specific things that we need more expertise on.
... the people who are currently active in headings have specialities more on the advocatcy side,not testing experts. Call for help.

Wilco: Confirming with Jeanne that the feedback from ACT will also go to the headings subgroup. Jeanne confirmed, yes.

jeanne: will also send to ACT

WCAG 2.x maintenance

<alastairc> https://github.com/w3c/wcag/issues/1818

alastairc: WCAG 2.x maintenance. We've been focused on WCAG 3 and 2.2 success criteria for 6 months to a year and haven't spent time on 2.0 and 2.1 issues in github. Most relate to understanding documents and techniques. There does seem to be a bit of concern about wanting to focus more effort on historic documentation.
... Wanted to open the floor. There are a couple of things that are in progress. Have a review of informing documents. Working with Michael Cooper to put more metadata in place to get people to the latest documents instead of the older ones.
... Can potentially look at fast tracking specific issues, but not sure how to define which ones to fast track, or not.
... Also, maybe create documentation to help people contribute changes to techniques.

<Zakim> Chuck, you wanted to ask what "fast track" means

alastairc: Current default fast track, issue gets put into github for triage, someone creates a pull request, then it goes into a survey to the group. How quickly we get to it depends on what else is on the survey.
... If we take a long time on the first issues, that can get us behind. We have a backlog of 459 issues.
... Also have a lot of issues that are discussion based and may have historically been on email list. 67 of the issues are marked as discussion.
... This may mean that some of these are duplicates or not important issues because they are more of a discussion that would have historically been an email thread.
... We are getting through the backlog, but does anyone have ideas on how we can speed up this process?

Wilco: Might want to organize smaller groups. Going through this with larger calls with 30+ people can take things longer. Divide the work up between people.

david-macdonald: Back in the day when we decided to do understanding documents, we didn't have an obligation to do it, but we decided to. At the time, accessibility was more of a niche thing. We are victims of our own success.
... WCAG is probably one of the top 100 standards of all time, when we think about all disciplines. But that makes a lot of us busy.
... the hundreds of hours we used to put in in the background, we don't have those resources anymore. Giving people the ability to just fix the stuff and push pull requests if they aren't changing the meaning, but are just helping explain. More of an informal look to see if something needs to be brought to the larger group. E.g., having a triage group.

<JustineP> Consider pulling from a pool of volunteers to tag/triage issues in Github so that we have a categorized pool that will inform priority/difficulty/process...discussion needed, easy fix, etc? Looks like David is addressing this suggestion right now!

david-macdonald: instead of a triage group with prioritization, having people with the authority to make changes that aren't in need of deeper review. If you choose people who have been around for a while, they should be able to describe.

Jaunita_George: suggests setting up smaller groups in a sprint structure, 2 week sprint cycles for taking on a smaller subset and triaging them.

alastairc: That sounds like a good idea, but we need to get people involved with it

JakeAbma: bringing up issues we do want to talk about together. Talking with a lot of people, and there is a feeling that people find issues in the documentation. We have a conversation, and then one or two people say they don't agree, and then we close the issue. But there are 20 or 30 people who say they do have a problem, and then this means that people feel dismissed (scribe is paraphrasing).

<JF> +1 to Jake. The response/feedback loop isn't working

JakeAbma: The issues still live on, and a lot of times we don't seem to close them in the proper way that people really have a feeling that the problem has been dealt with in a way where people feel they have been understood and listened to.

<Zakim> Chuck, you wanted to echo what I think I heard DM say.

JakeAbma: if we can set clear boundaries on why or where or how, that might help.

Chuck: echoing David, a triage team with the power to make updates. Clarifying, that team would not need to bring the responses to the larger group.

david-macdonald: yes. And we can have those changes documented where others can review, and if they have concerns, can bring them up.

Wilco: elaborate on asynchronous. Most of the things that get merged do not get discussed on a call. The biggest bottleneck is that everything has to go through the survey and call process.
... If we can create a process where a number of people we trust can approve pull requests, and a process where anything that is not editorial goes to the mailing list for a review.
... This way, we can be completely asynchronous and get through more in a week.

AWK: thinking about how we started. I have some concerns about having a small team of people who are empowered to say that something is right. When we started, all comments went through the mailing list. Some things were editorial and to be reviewed, but the techniques would be updated every 18 months to 2 years. Much lower volume of comments coming in.
... some of the requests, I feel are attempts to redefine the normative language by changing things in the documents, and those things need review for sure. If we have a team to merge changes, we would want to reestablish some sort of schedule (quarterly, half year) so that people have a chance to review changes.
... Part of my problem is that there is so much information flying around in different ways. Too much information to take in and do the rest of our jobs.
... If we did that, we need some way to sort these as editorial or not. The chairs have done a good job of just handling things that are editorial, but there needs to be some way for a review process for other changes.

Jaunita_George: suggestion to structure the tickets into releases. At the end of the release, we can review all the changes, take out any folks disagree with, and then release the rest of the changes in a publication.

<Zakim> alastairc, you wanted to say that it's has been very hard to know which PRs will get through.

alastairc: Triggered by Jake's point, knowing which changes or pull requests are going to get approved or significantly modified before they get through. I'm not new to the group, but I think I'd have a less than 50% chance of knowing which particular change would get approval and move through. It may seem obvious until we discuss it. We have a wide range of things we are looking at. Having some kind of quarterly review or structured releases, or somethi[CUT]

<Zakim> bruce_bailey, you wanted to say +1 to AWK, tendacy to make normative change in Understanding

alastairc: necessary.

<bruce_bailey> https://www.w3.org/TR/WCAG21/#timing-adjustable

bruce_bailey: +1 to what Andrew said, let's have at least quarterly review. I do see a tendency to try to change the normative meaning through editing understanding, so that is an issue. One example that really stuck with me was with timing adjustable (link above). Nothing malicious or people trying to move the bar. Just an understanding because the prose isn't as good as it could be.

<Wilco> -1 to quarterly, btw

alastairc: We will come up with something and get it in place to help with current bad bottlenecking. If anyone would like to get involved in the triage and dealing with things process, please let Alistair know.

WCAG 2.x issue resolutions (Q1-6) https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/

Question 1 - Text spacing, "setting all of the following" to "any" (NORMATIVE) #930

alastairc: Text spacing, issue 930, is a normative change.
... Ambiguity if all of them have to be applied or if it can be any. (See survey details linked above for specifics)
... Four people agreed with the change, five people disagreed. At the moment, on that basis, we wouldn't be making a change.
... Based on survey results, the problem is really with the grammar.

david-macdonald: my understanding is that what we are trying to do is to have you set all properties to maximum value. All of them have to be met. If any are not met, then you are failing. Then you only do one test. I believe that is why we worded it this way.

<laura> +1 to david

<jon_avila> But only the ones that exist in the technology

alastairc: confirming that David's recommendation is that we did mean all of them at the same time. Criteria was written to make sure that it was straightforward to test. Michael disagrees with that.

<Zakim> Chuck, you wanted to say we have built in a subset already

alastairc: Laura also of the same opinion (disagrees), and Oliver and Gundula, too.
... In terms of whether we would make a change or not, we would need to be persuading those who disagree to change their mind. Would anyone like to make their case?

<AWK> Changing it will mean that all combinations of those four items need to be tested, yes?

alastairc: Michael Gower's comment is a good response to the issue.
... yes, it means that they would need to be independently tested, plus two or three, plus all at once.

Chuck: commented that this might lead to 24 combinations of testing

alastairc: thinks it is 10 (did maths in the issue)

<Wilco> +1

GN015: The way it is worded, you can't just change all four and make sure it works. A lot more testing required that leaves holes. If you change all four properties, people might think that it doesn't need to be verified.

jon_avila: I think we have to test then all together. Testing individually makes this a lot more complicated. The SC was written for success together.

alastairc: if our intent was to set all four at one time, scenarios where one along causes a failure, it would be an outside case and require a significant amount of testing to ascertain that. Response will be along the lines that this is as intended.

<jon_avila> +1

<mbgower> +1

<bruce_bailey> +1

<JustineP> +1

+1

<GN015> +1

<AWK> +1

<Makoto> +1

<david-macdonald> 1

<Ben> 0 feel like I need more time

<david-macdonald> +1

<johnkirkwood> +1

<OliverK> +1

<Wilco> -.5

alastairc: you will get more time because I will run the resolution past the group, and the response. In the meantime, worth reading the threads. Asking Wilco if there is an alternative.

<JF> +1 to Wilco

Wilco: not sure should include the sentence about the subset is a corner case and it is a lot of work. We argued that this is the correct way to do it. Should be careful about saying that changing it would be too much work.

<jon_avila> I'm fine with Wilco's comment.

Wilco: Correction: changing it would mean that testing is too much work.

<Wilco> +1

<mbgower> I think you _can_ say something about the intent being to make testing straightforward/efficient

RESOLUTION: The intent of the SC was to set all 4 simultaneously. We will not change, and we will review the proposed response at a later date.

alastairc: if someone would put a draft in the github thread, that would be fabulous.

Chuck: will handle the topic.

Question - 2. Update benefits of 2.5.1 pointer gestures #747

alastairc: most people agreed with the updates. Taking a look at Gundula's something else note, and Michael suggested an adjustment.

mbgower: There are some benefits for cognition. We did talk about how this reduces confusion, and concerned that this is removed.

alastairc: asking Jake for context, should we be stripping out the benefits listed for users with cognitive or learning disabilities?

JakeAbma: confirming that yes, the point is that it is not focused on that, so makes sense to pull it out.

alastairc: there is nowhere else where the document talks about the cognitive side, and it is not obvious how this would benefit.

mbgower: This is covering author-created complex gestures. Not standard device gestures. By definition, this will be unusual, and you are counting on the user to be able to understand what the gesture is. One of the arguments for supporting simple gestures is that they are predictable and clear. If we want to put more in the understanding document...

<JustineP> +1 Mike

alastairc: Perhaps this means we need more context as to why it was included, rather than removing it.

mbgower: will take on responsibility of working on the clarifying content to add.

alastairc: assigning that responsibility to Mike
... asking Gundula if something else was because something had been removed

GN015: one side was replaced with puff based. And double tap was suggested as a simpler gesture for a pinch, but double tap can be a complex gesture for some people. Some individuals with motor difficulties may not be able to execute a double tap because it is time dependent. It is a matter of speed and coordination. Recommend to not use it as an alternative gesture for something else.

<johnkirkwood> +1 to double tap point by Gundula

alastairc: asking Mike to look through survey comments when working on this test. Agree that the normative content is very much based on puff based.

mbgower: will attempt to bring is as many of the comments as possible.

<alastairc> Michael has been assigned to update

alastairc: we won't resolve this one, but Michael has been assigned to the update, and we can move on.

Question - 3. Text spacing: does it require compatibility with one or all methods? #975

alastairc: Patrick created a pull request to clarify this. Not specifying how to do it, but rather if it is done, wouldn't break.

OliverK: argues for keeping the older version because for the same reason as Gundula.

alastairc: Looking at Gundula's comment (see Survey).

GN015: When people can override, if in contrast it says "when the user overrides" then the expectation is that it will succeed. As the newly added sentences clearly described, it should work. Not the expectation in the success criteria to react on each and every method. I feel that this is worded that it should work with a bookmarklet, but I'm not sure it does.

alastairc: not sure read the same way. The intent is to make sure people can override. Implies that it is up to the website to allow or block it. Assumption of the criteria is that they can, but what happens when they do is how whether content passes or fails.

GN015: bookmark, original does not react in iframes. Doesn't work if they come from different servers, only the same servers. Stylus updates CSS before loading. There are a lot of pages failing on the bookmarklet but succeeding on stylus.

<Zakim> Chuck, you wanted to suggest that we probably won't solve in remainder of today's call, and should discuss in a future call.

alastairc: will need to come back to this next time. We will consider how to speed up the process. If anyone is interested in being part of a group to triage, please get in touch.

rssagent: generate minutes

This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/section of the understanding doc/section of the understanding doc to document outside research to back up our claims/
Succeeded: s/readability/repeatability/
Succeeded: s/are the people who are advocates, /have specialities more on the advocatcy side,/
Succeeded: s/Wilco/David/
Succeeded: s/woudl/would/
Succeeded: s/understanidng/understanding/
Default Present: AlastairC, Chuck, jeanne, JF, Ben, Jennie, Makoto, JakeAbma, MichaelC, juliette_alexandria, Rain, sajkaj, AWK, johnkirkwood, bruce_bailey, david-macdonald, Nicaise, Raf, MelanieP, Laura_Carlson, stevelee, mgarrish, KimD, JustineP, Wilco, KarenHerr, Detlev, mbgower, Francis_Storr, OliverK

WARNING: Replacing previous Present list. (Old list: AlastairC, Chuck, jeanne, JF, Ben, Jennie, Makoto, JakeAbma, MichaelC, juliette_alexandria, Rain, sajkaj, johnkirkwood, bruce_bailey, david-macdonald, Nicaise, Raf, MelanieP, Laura_Carlson, stevelee, mgarrish, KimD, JustineP)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AlastairC, Chuck, jeanne, JF, Ben, Jennie, Makoto, JakeAbma, MichaelC, juliette_alexandria, Rain, sajkaj, AWK, johnkirkwood, bruce_bailey, david-macdonald, Nicaise, Raf

Present: AlastairC, Chuck, jeanne, JF, Ben, Jennie, Makoto, JakeAbma, MichaelC, juliette_alexandria, Rain, sajkaj, AWK, johnkirkwood, bruce_bailey, david-macdonald, Nicaise, Raf, Wilco, KarenHerr, Detlev, mbgower, Jaunita_George, Francis_Storr, OliverK
Regrets: ShawnL, MatthewOrr, SarahH
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: Rain
Inferring ScribeNick: Rain
Scribes: ChrisLoiselle, Rain
ScribeNicks: ChrisLoiselle, Rain

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)