Meeting minutes
New web irc client
alastairc refine categories from card sort
… may run long
Any announcement?
Avon, ux researcher at intel, greetings
Nayan greetings, web remediation service
Subgroup Updates
<Chuck> Welcome Avon and Nayan!
alastairc: only pub subgroup has more than a week
wendyreid: we had scheduling miscommunication , should have more to report next time. Just getting calls sorted
Accessibility supported https://github.com/w3c/wcag3/discussions/53
alastairc: focus appearance subgroup has just started, but nothing to report
[alastair screen sharing]
alastairc - summary is that we are looking for proposals and feed back
… Jon thinks we need accessibly supported, but might be at higher level
… stephan suggested turning it as user expectation
alastairc: What we are looking for is some proposals for how things might work for WCAG 3. We are short on suggestion in issue thread.
… this introduction aims to help people make suggestions
<alastairc> https://
alastairc: could be a middle of two positions -- we need something
[pause]
alastairc: This was second introduction to topic, please take a look. We need suggestions.
John Kirkwood asks for some clarification as to what suggestions chairs are looking for?
Lori Oakly: We seem to be looking for a definition, but thread comments seem to be encompassing who concept.
alastairc: So as a counter example, what is not working well, is extreme example of author has responsibility of knowing code is working well for PWD.
… other extreme is that following spec absolves author of any and all responsibility.
alastairc: Are some ideas for base lines, for a middle possition, but not concrete enough.
John Kirkwood: Any dated aspect, of say database, will be problem for regulators.
GreggVan: When we talked about accessibility supported back in the day, focus was not so much on author but that we would not have SC which were not already supported by UA.
… Other factor was that "only works with JAWS" was not practical because was relatively expensive.
… Nowadays Accessibility Supported should include readily available, at modest cost, supported by major browsers.
… Unfair to expect people creating web pages to know anything about screenreaders in any technical detaill.
alastairc: I will be trying to rewrite comments today into draft propossals.
… if we have something that works for ePub but accessiblity supported in HTML could be different.
Makoto: I don't have a proposal, but want to comment that evidence that AT works is very important in Japan. Documented technics for JAWS/NVDA...
<ShawnT> Wasn't there some type of database created on the WAI website? Shadi talked about it at TPAC in Vancouver.
Makoto: may not work with PC Talker -- practially the only screen reader available in Japan. PC talker tends to have less support for newer HTML and WAI-ARIA features....
… we want to use same international standards as others, as WCAG 2 has been. We are looking to adopt WCAG 3.
alastairc: Agree, that one driver for this new approach for accessiblity supported.
wendyreid: Current definition is very strong and complete. If anything, we might go deeper into what is expected of the UA...
… there is less an issue with code for ePub for example, but support from ePub readers varries...
… Acessibity supported should be enough for author on platform. And AS must mean things Just Work for the end user.
Scott O'Hara : not all features are supported across browsers and accross operating systems...
… It becomes almost imposible for developers working on those platforms to know what is supported...
… If a technique works on Windows using JAWS, does that mean it is supported? Too many factors to consider, and they multipley.
<Duff> Concur with Wendy. Find a definition that pushes on UAs and ATs to raise their game. Perhaps a scoring / ranking system that includes cost, platform coverage, etc.
<Zakim> GreggVan, you wanted to say Accessibility Supported -- meant supported by 3rd party AT and accessibility features in browsers and Operating systems
<webirc18> WCAG isn't place to push UAs and ATs, it's for content authors/developers
GreggVan: When we talked about AS, it was AT plus common features in browsers.
dan_bjorge: From perspective working on testing engine, original intent was what technics could we rely upon?
… When we are testing, questions come up all the time about techniques being available or not...
… It is a gradual process over time. When can developers rely upon approach or not? Webaim has a survey which helps with that...
… I don't think static bar is sufficient. Need to account for region and language.
<scott> +1 to dan's comment
<Zakim> jeanne, you wanted to say that early research work for WCAG3 use cases
dan_bjorge: Current approach in WCAG2 is reasonable.
<dan_bjorge> axe-core's accessibility supported position, if folks are interested: https://
jeanne: I want to remind folks about reasearch from early in WCAG3 development. Competing needs, as Mokoto raised, for small AT markets...
… But also long-term bugs with popular AT problematic for authors. Technic worked when using NVDA -- is that Accessiblity Supported? Is that fair to authors?
<Nayan> since I am new to this, have a cross section of users who need accessibility tools (especially visually disabled) been part of consulting on this process?
alastairc: We are still looking for written proposals, so people can comment.
… UA vary by region and generally unpredicatable...
<Nayan> but people who use screen readers are not part of this process it seems?
alastairc: but rather than marking AS or not, methods include information so audits can make the appropriate determination based on their markes?
<ljoakley1> Nayan, I work with JAWS about 25 hours per week
Nayan: Are these developed with the input of users of screen readers? We see disconnect from users with VoiceOver and NVDA. Can we suggest people to be included?
… lawsuits are a strong driver in the market, and regulation cites to wcag without good effect.
<Nayan> 22000 lawsuits mention WCAG
alastairc: Yes, over the years, lots of input from daily users of screen readers and other AT.
alastairc: Import to have accessibility support reflect reality.
Kevin White: Our responsibility is to define standard. But W3C does not role in setting regulation.
<Zakim> mbgower, you wanted to say that just thinking about screen readers, which one's behaviour is the one that should count to accessibility supported? At what point is it a bug with the SR? Is it just a foible of the vendor decision?
<scott> https://
Mike Gower: There is work from APG group, Matt King, putting some parameters around accessibility supported...
… Hard question around if screen readers behave differently , how can baseline expect behavior?
… How can one define AT used by a group of users?
… this points to an approach in WCAG3 that developers document what there assumptions are...
… then WCAG 3 might set expectation for such claims.
<scott> the link i posted is what Mike was referring to. The ARIA AT project. It is presently focused on documenting and advocating for consistency with ARIA features. It is not in scope to go beyond ARIA at the moment
<alastairc> Perhaps Baseline/bronze could be "conforms to standard regardless of support", then have assertions for testing across AT?
<Nayan> are we creating a "standard" or guidelines - that needs to be clear.
Introducing List of Outcomes https://docs.google.com/document/d/1mxIImo7FgjyDzEu6J5jWvHIDFC_07TOR46Hn4hIAQvU/edit
alastairc: I have added some comments in Discussion #53 , conversation has definitely given me more to think about.
<Chuck> Reminder, the conversation on accessibility supported continues here: https://
alastairc: To give a quick update, again drawing from previous conversations and results of card sorting exercise...
… Jeanne Kevin and others have helped sort. Please comment in the Google Doc and may link up a discussion on GitHub.
<Chuck> perhaps this one: https://
alastairc: Using feed back is questions about assumptions...
… not useful is simple opinion like "this should not be an outcome" ...
… We have updated some definitions and assumptions.
… Combined a few topic (ex. images and media)
… kept something separate when card sort left some items separted.
alastairc: We had a few items, e.g. policy, which are not a fit into single category.
alastairc: Now is good opportunity to provide comments. Next draft will probably not include them all. We have removed quite a bit of duplications.
Graham: First impression, fatique and triggers do not fit "adaptive" well.
alastairc: The first pass grouping now came from card sorting, but fair comment.
WCAG 3 Requirements
alastairc: Requirements included in agenda. These are things WCAG3 will be judged against.
… Draft needs to be clear about meeting.
alastaircL Issue and related PR is pass at providing more clarity.
… File comparison highlights the changes. Making more plain language and reflects conversation in AG calls over last several weeks.
alastairc: The "motivation" one is rewrittedn to be less binary.
<alastairc> w3c/
alastairc: Not too much conversation on the PR #735 so please be encouraged to provide feedback.
jeanne: My comment was a minor thing about saying true / false rather than pass / fail .
… Larger issue is how to maintain? This draft seems to only be about informative documents, but that is not enough. Its a major change to drop normative from regular mainatence.
<GreggVan> +1
alastairc: Change is under "Flexible Maintenace and extensible"
kevin: I have some concern about process for deliberatin on normative publications.
<dan_bjorge> yes
<mbgower> Agreed
wendyreid: We has something of similar concern in Publications. I think it is a good idea, but how to achieve it?
… ePub working group as an example, we have 3 TR tracks, but extensive Rec Track documents and, longer term, that might be a model for WCAG3.
… Series of informative working group notes gets us over the hump easier.
<kevin> +1 to what takes lots of work!
alastairc: Build on Jeanne IRC comment, we are looking to evergreen process. But I am hearing from Jeanne that normative material should be in scope.
<Zakim> Chuck, you wanted to ask for scribe change
<Zakim> jeanne, you wanted to propose adding the phrase "following the W3C process" -- that was assumed
jeanne: We can add a phrase to make it clear we're following w3c policy. At the time, they were exploring different evergreen processes. We could safely keep this, and clarify.
dan_borge: I understand there are lots of good reasons to allow the guidelines to evolve over time, but I believe it should not be easy to update. It takes a long time to adapt to changes in the guidelines.
… especially in light of what Kevin said. Most take ups rely on a timestamped version of the guidelines
… I wouldn't object with the new parenthetical content
<jeanne> The hybrid evergreen policy date-stamped versions within the Evergreen standard.
<alastairc> w3c/
alastairc: I'm going to commit that. Over the next few days, if people could take a look at those changes, it would be good to get more thumbs up, as these are the biggest changes so far.
… The other issue is #732. Wilco created a PR to mitigate his own comment
… This is in the opportunities section, under Measurable guidance, (line 116)
… Jeanne, is this the one you meant should be true/false, not pass/fail?
Jeanne: Yes
alastairc: I dont' think there's any problem integrating that. [Continues to read from PR #732]
<bruce_bailey> https://
alastairc: This is not part of the requirements section. It is a statement of direction we are exploring.
<Nayan> What Alastair just read - where is that available?
<Nayan> is that on the google doc?
alastairc: There is an update to the Readability part of the requirements
<alastairc> https://
alastairc: I don't think there were any other comments.
… Please have a look and give a thumbs up. If you see something with 6 thumbs up, you can pass to the next one.
… I think that was all the requirements one. So, a bit in advance of our agenda, we can move to WCAG 2
<alastairc> https://
WCAG 2 issues https://lists.w3.org/Archives/Public/public-wcag2-issues/2024Mar/0003.html
alastairc: This email went out a few weeks ago.
<mbgower> https://
mbgower: Running through, we are using the github project board. Each column is a step in our process flow.
mbgower: We have some columns when things are sent for approval, we sent notice via email, that contains a list of items in the approval column.
mbgower: We have 2 week adoption policy (this time 3 weeks for CSUN)
mbgower: This is the part of the process where we make the working group aware. We are trying to get at least six thumbs up.
mbgower: I'll go through the items, 3699
mbgower: This is a PR by someone outside the task force, its a substantive editorial change. It's not just tweaking some language to clear things up, it is changing the meaning of the understandings doc.
<bruce_bailey> https://
mbgower: Applying this sc ... it's more important to set the line height to improve readability. The prior sentence was <reads from PR>
mbgower: This is trying to make it more readable. If you think this improves please support, and if you think that this isn't the right direction, please leave a comment.
mbgower: Line 93, the existing information has examples but they are not in a list. We have put the examples in the list, the info is largely the same.
mbgower: I don't believe that the info has changed. From 107 onward, this is improving presentation.
mbgower: Some tweaks and words added, the meaning has not changed.
mbgower: That's it.
mbgower: This is a good example, not a lot of change, but meaning is potentially changed, we marked substantive.
mbgower: The next one (3572), we updated html files for xslt/xml
<bruce_bailey> w3c/
mbgower: This is a fix of "code", it doesn't change any of the meaning of information, it's a "bug" fix.
mbgower: We do have a qa process to review.
mbgower: Next one 3657, adding a note for focus appearance.
<alastairc> w3c/
mbgower: This clarifies...
mbgower: We used a term encloses, but we didn't have it in the actual wording. We've removed "enclose" and said permiter.
mbgower: The rest of these are quick. Syntax (3381). Main purpose is fix some typos.
<bruce_bailey> w3c/
mbgower: Lots of files changed, but literally host cleaning, doesn't change any meaning.
Francis: I made this PR October last year. Patrick did same thing, I spent time merging mine with his stuff and addressing conflicts. The PR is ready.
<bruce_bailey> w3c/
Francis: Review the merged one on Friday.
mbgower: We will review on Friday, and leave it in "sent for approval". Once closed, we probably don't need to review it again.
Francis: Looks like Patrick approved the one I did yesterday. Should be good to go.
mbgower: I don't think there's need to go through the rest: 3584 and 3735.
<Graham> It is worth noting 3657 has invalid `<a>` elements in it. I left a note
<bruce_bailey> w3c/
Alastair: That concludes our material today. If folks can look at the first couple we discussed today, that would be appreciated.
<bruce_bailey> w3c/
Alastair: An email will go out with fresh issues from the WCAG 2 task force.
Graham: I see that we have some elements... are these actual problems? Actual issues?
Alastair: Probably not.
Alastair: you can leave a comment and we can address that.
Alastair: Meeting adjourned.