Accessibility Guidelines Working Group Teleconference

14 Aug 2018


AWK, bruce_bailey, Chuck, alastairc, Glenda, MichaelC, Brooks, JF, marcjohlic, Katie_Haritos-Shea, kirkwood, gowerm, Roy, AllanJ, Laura, Detlev, david-macdonald, KimD, jon_avila, Rachael
Brooks, Chuck


<alastairc> https://rawgit.com/w3c/wcag/identify-input-purpose-updates/understanding/21/identify-input-purpose.html

<alastairc> scribe:Brooks

Process discussion and feedback collection reminder https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JulSep/0131.html 

ac: We are collecting feedback for another couple of weeks, until August 24. Please provide feedback on process.

Potential WCAG 1.0 deprecation

ac: The W3C is now deprecating old standards. We want to ask for comment about deprecating WCAG 1.0.

<Detlev> +1 for deprecation

ac: Does anyone have any concerns?

Bruce: Is there a formal definition for deprecation? With HTML 3 or 4, there wouldn't be much harm there. With WCAG 1.0, there could be more at play. Do we need stronger language than "deprecate?"

<laura> didn’t HTML WG use the term “obsolete” at one time?

ac: I can ask about that. Michael, do you have any comment? What does deprecate mean in the W3C context?

mc: What we've been looking at is "retired" or "obsoleted"

<bruce_bailey> +1 for "obsoleted"

<scribe> .. Retired means it was never recommended. Obsoleted means it was recommend, but no longer recommended. Rescinded, is another term we have been considering. Rescinded means we made a mistake, and want to take the specification back. We aren't really looking at using rescinded.

UNKNOWN_SPEAKER: Deprecated refers to features.

<kirkwood> +1

<david-macdonald> +1 for obsolete

<AllanJ> +1 for obsolete

<Rachael> +1 for obsolete

ac: Does anyone have any objections to using the term "Obsolete" for WCAG 1.0?

<MarcMobile> +1 to marking 1.0 as obsolete

<Zakim> bruce_bailey, you wanted to ask if W3C defines what it means by deprecation?

jf: Have we done the due diligence to ensure that obsoleting isn't going to impact legislation? I don't want to be hasty with this action.

<david-macdonald> https://www.w3.org/WAI/policies/

mc: We can mark something as obsolete that is being used. The main impact is that it dissappears from the list of specs from the main TR page.

<jon_avila> maybe obsoleting it would encourage update of standards in legislation.

<alastairc> Example for HTML: https://www.w3.org/TR/html401/

<david-macdonald> No countries listed as referencing 1.0 except old 508, but that's been updated

<Ryladog> +1 to a warning first

mc: One of Judy's thoughts is that there should be a fair warning period. There are still questions about how long this period should last, and how do we make sure everyone that needs to know gets the message.

<JF> I would prefer we take the additional step of "advanced notice"

<Chuck> +1 to warning and obsoleting

dm: There's only one country on the list of countries who still have policy dependencies, and it looks like there is only one country and they are still referencing 508. Shouldn't be a problem to make it obsolete.

<KimD> +1 to warning - maybe add to W3C newsletter? and obsoleting

katie: Who should we contact to make sure that the folks who need notice get it?

jf: we can count on informal networks to communicating out, but likely should seek additional input on how to properly communicate out.

<gowerm> What about superceding it?

katie: I think it is a good idea to notify people.

<bruce_bailey> FWIW, it looked to me like the reference DM cited was from the Dept. of Education and was a reference to WCAG 1.0 impact on the 508 proposed rule from 1998 and 1999.

<jon_avila> Us obsoleting this tells people they need to update their legislation -- it doesn't mean you can use it. Not obsoleting encourages people to say it's ok to use and sanctioned

<gowerm> https://www.w3.org/2018/Process-20180201/#rec-rescind

mc: Obsoleting just means that's there is a message that people should use something newer. Superceded may be more on point with what we really mean here.

<Zakim> MichaelC, you wanted to mention supercede vs obsolete

<jon_avila> I agree we should let people know

mc: I'm not sure what kind of benefit would come by providing the warning, because the old standard will still be available and usable.

Katie: Superceded seems to be a better term. It is more in line with what we mean.

<gowerm> +1 to superceding, and doing it now

<bruce_bailey> IMHO, any regulatory body still referencing WCAG 1.0 will not take notice of a warning from W3C...

<jon_avila> I'd agree superseded is good designation

mc: W3C management will not obsolete WCAG 1.0 without input from the agwg.

<KimD> +1 to "Superseded" rather than "obsolete"

ac: Questions I have are what channels to we communicate out with, and are there concerns with obsoleting, and how long of a time frame do we create between the decision to obsolete and when it happens.
... Is a month enough time?

mc: No, that's not enough.

<Zakim> bruce_bailey, you wanted to say I do not think we have channel to reach who we would want to reach

<gowerm> +1 to Bruce

bruce: Anybody that is going to be impacted by this are not likely going to be able to be reached. If they were going to update, they would have done that already.

katie: I think that if we advertise this through the accessibility community, the message will get to the people who need to know of the change in status.

<laura> Arizona Board of Fingerprinting https://fingerprint.az.gov/accessibility-statement and Birmingham Airport : https://www.birminghamairport.co.uk/accessibility-policy/ seems to be using 1.0

<gowerm> It's superceded. They can keep using it, but are now on notice they should do something about it. The notice that it is being superceded seems to immediately achieve what we want.

<KimD> We should show a good-faith effort to notify

<laura> can’t hurt to notify

Process discussion and feedback collection reminder https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JulSep/0131.html 

ac: If someone comes back and says we wish we had been notified, we can say we tried.

Survey on role=status technique https://www.w3.org/2002/09/wbs/35422/TechniquesforApproval/

<alastairc> https://rawgit.com/w3c/wcag/tech-using-role-status/techniques/aria/aria-status-role.html

ac: To Detlev's point, I don't think UA or AT notes should be part of this.

dm: we do have a history of providing info for accessibility support in techniques. I think it is not a good idea to not UA or AT support notes, though.

detlev: I thought it might be worthwhile for developers who use techniques to provide UA and AT notes who want to test their implementations against the notes. Support changes, of course. This is not normative information, so it may be useful to plan on providing these notes and updating periodically.

ac: It would be significant undertaking to maintain the UA and AT notes.

detlev: It would be good to point out the gaps in support through UA and AT notes.

<Zakim> gowerm, you wanted to say that there are issues I identified. My intent had been to open bugs. Maybe we should have a maintained page for all techniques?

dm: The two examples in this proposed technique seem a bit confusing. Not sure this is ready.

mg: There are some differences in behavior. Status is pretty well supported. Not sure if there is full support for the atomic state. I'm finding less support for the log role. I'm concerned about maintenance issues related to putting UA and AT notes in techniques.
... I wonder if it would be useful to centralize our findings, then to notify UA and AT manufacturers instead of sending one-off bug reports?

ac: If we can put all of this into one place, timestamped, with links to the examples that have been created, that might be beneficial.
... Any suggestions on where we would store this information?

<david-macdonald> https://rawgit.com/w3c/wcag/example-aria-role-status/working-examples/example-aria-role-status/shoppingcart.html

ac: If it were part of the repository as part of a separate standalone section, that would allow others to contribute. I'm in favor of this information being in one centralized location, rather than spread out throughout the techniques.

<gowerm> I wasn't suggesting this is for developers. I was suggesting it as an indication of due dilligence for our technique approval, and a centralized point for getting user agents to resolve.

detlev: Developers are likely to go directly to the specific techniques they are interested in learning about, and might not know to go to a summary page to look for that information.
... The idea that the creators of these techniques would keep up with support for the techniques they've written is worth considering.

ac: Would the UA and AT notes be valuable, given the quick pace at which accessibility support changes?

<david-macdonald> Testing results on this technique> JAWS, NVDA ok with status, no need for aria-live and atomic, Mac VO and safari OK without aria-live

ac: there is a lot of overhead involved with providing these types of notes. Any other comments on changes for this technique?

dm: I just did a quick test on this technique. Status role has decent support, but some browser and AT combinations don't announce it as expected. I don't see a good reason to throw the extra attributes in there.

<gowerm> I'm fine taking the default attributes off. I thought it was a good way of showing the defaults

<Detlev> I would like to re-run my mobile tests without those attrivutes...

dm: we aren't going to get any additional benefit for having the default attributes added.

mg: I'm fine with removing those.
... there isn't as good support without them, though.

ac: If mg can take out the references to the additional attributes, this technique seems ready to publish.

mc: Wednesday, publishing things that are ready to go on my to do list.

ac: Sounds good. We are making progress.

Techniques needing work/review https://github.com/w3c/wcag/pulls?q=is%3Apr+is%3Aopen+label%3A%22Ready+for+initial+review%22

<Detlev> Here is a page both with (example 1) and without (example 2) aria-live and aria-atomic attributes: http://3needs.org/en/testing/code/role-status.html;

ac: we've got a few other techniques that are almost ready. Jake has got some updates to make, and he
... will be back next week.
... we've also got a couple of techniques that have been updated by David.

dm: I've made updates based on people's comments.

ac: let's use +1 as a means of approving, versus using a thumbs up.

dm: feel free to communicate directly with me via email with comments and suggestions.

ac: Tell us about what's left with role="log"

mg: I've got some questions about how to use aria-relevent with this technique. Hoping to have that ready to talk about this next Tuesday.

ac: Knowing when a technique should be used is especially helpful. This information should be part of a heading.
... Anyone have any questions about reviewing or adding techniques?

<alastairc> Top tip: rawgit.com homepage is easy to create the link.

marc: If folks could add the RawGit version link, and other little touches like that, it will save people time in reviewing techniques.

ac: copy the URL you are working on, go to rawgit.com, then paste it into the home page input, and get the rendered rawgit link out of the interface.

<marcjohlic> Adding things like a rawgit link to your technique, your examples, a link to the SC and Understanding doc all in GitHub for your technique can really speed things up for reviewers.

detlev: What is the preferred process of creating a new technique in GitHub. Is a fork or branch better?

ac: Use branch within the W3C repository within the GitHub interface, unless you are GitHub expert.
... Start a new branch from Master, work on that one file, call the it something similar to what the technique is labeled. Do the pull request back to Master.
... This is the easiest way you can create a new technique.
... Any other questions about reviewing or updates?
... put the rawgit link into the description field of the pull request.

<Chuck> Scribe: Chuck

AC: Any other q on techniques?

Detlev: I assigned myself hover on focus. Have a question, will put it in writing.

AC: If there's any conversation, we can talk about it next week.

MG: I pushed changes for status rules and ... technique.

AC: I'll take a look at those this evening.

Update to Understanding doc for 1.3.5:

AC: Late addition. <looking for link>

<alastairc> https://rawgit.com/w3c/wcag/identify-input-purpose-updates/understanding/21/identify-input-purpose.html

AC: General explanation... was it a general overhaul?

JF: First of all, there were 2 issues posted, regarding... scope that needed to be addressed. Original understanding had number of spelling and grammar mistakes..
... 2 benefits. Really driver for success criteria... most viable working technique is using autocomplete, makes forms easier for filling out.
... Important both benefits were articulated. The fact that today autocomplete is the only viable technique is not a big concern (more techniques will evolve)...
... We can personalize the interface. Larger goal is machine understandable technique. This is a "perceivable" technique.
... I also have linked to section 7 of the sc.... reducing dependence on autocomplete in html5. Which we agreed to. That's the high level overview.
... Much of content is from existing understanding.

AC: There were some related resources there, or were you looking for something different.

JF: I don't have somethign specific from COGA. Personalization task force is one layer removed from... they are looking at fleshing out a larger taxonomy, but alternative methods of attaching data to interface...
... Perhaps something like "purpose equals"... there is more working being done in this space. Part of the driving force for 1.3.5 and 1.3.6.
... I was mostly focused on intent part.

AC: Going from memory... ok... Sure there will be a link or 2 from task force. Apart from that I suspect we'll put a survey out so that eyes can get on this and get reviewed.

JF: It's an action item I took on 2 weeks ago.
... It was posted by Andrew that it's an activity I was assigned.

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

AC: 3.4.3... might be transfered from previous repo.

<JF> as an FYI, this is the current info discussion for other methods: https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content

AC: If we can close a couple of issues that would also be good.

JF: I believe that's there's another one.

AC: In which case we are at the end of the agenda.
... with 50 minutes left. Unless any questions... relating to techniques. I suggest we take back 40 minutes, pick a technique from list...
... which is link from item 4, pick from top, and have a look. Comment or give +1.
... Any questions?
... Got a few people on call, hope we get that many plus 1's.
... Talk to you next week.

<bruce_bailey> bye

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/08/14 16:10:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/is is/it is/
Default Present: AWK, bruce_bailey, Chuck, alastairc, Glenda, MichaelC, Brooks, JF, marcjohlic, Katie_Haritos-Shea, kirkwood, gowerm, Roy, AllanJ, Laura, Detlev, david-macdonald, KimD, jon_avila, Rachael
Present: AWK bruce_bailey Chuck alastairc Glenda MichaelC Brooks JF marcjohlic Katie_Haritos-Shea kirkwood gowerm Roy AllanJ Laura Detlev david-macdonald KimD jon_avila Rachael
Found Scribe: Brooks
Inferring ScribeNick: Brooks
Found Scribe: Chuck
Inferring ScribeNick: Chuck
Scribes: Brooks, Chuck
ScribeNicks: Brooks, Chuck
Found Date: 14 Aug 2018
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.)

[End of scribe.perl diagnostic output]