W3C home > Mailing lists > Public > public-silver@w3.org > March 2019

Re: WCAG 2.2 acceptance criteria

From: John Foliot <john.foliot@deque.com>
Date: Thu, 7 Mar 2019 19:23:56 -0600
Message-ID: <CAKdCpxx3XTsjSHEuTFJnyfW7FiJp9ok6Ez2-7nJS2mV3Dc6HrA@mail.gmail.com>
To: "Delisi, Jennie (MNIT)" <jennie.delisi@state.mn.us>
Cc: Chuck Adams <charles.adams@oracle.com>, Glenda Sims <glenda.sims@deque.com>, Alastair Campbell <acampbell@nomensa.com>, "lisa.seeman" <lisa.seeman@zoho.com>, COGA TF <public-cognitive-a11y-tf@w3.org>, Silver TF <public-silver@w3.org>, Andrew Kirkpatrick <akirkpat@adobe.com>
[Edit]

s/Silver WG/Silver TF

JF

On Thu, Mar 7, 2019 at 7:22 PM John Foliot <john.foliot@deque.com> wrote:

> Hi Jennie,
>
> No worries. Having spent a lot of time earlier-on in the COGA TF, and
> being heavily involved in the WCAG 2.1 effort, I am aware of the proposed
> SC that didn't make the first cut, and why. At one point in that process,
> there was some animosity and accusations tossed about that proved to be
> counter-productive to the larger effort, and so I was worried that we'd
> started down that path again.
>
> The issue for me isn't that future SC will require manual testing - we've
> got plenty of those already - but as noted, as we start to be more specific
> and detailed in what we ask, there needs to be a mechanism that mainstream
> content creators can readily rely on, solutions that are robust, that scale
> for large organizations, and are relatively easy to implement, with a means
> to accurately test for compliance (and again, at scale). This is doubly
> important if we want a new SC to be at level A or AA. Sadly, to my mind,
> trying to standardize on some un-achievable ideal usually results in
> frustration and disappointment: the sad reality is that we'll never
> standardize requirements that meet *all* user needs, so the best we can do
> is try and widen the circle to include more and more users.
>
> For example: Plain Language.
>
> We all know that plain language is important for comprehension, more so
> for those users with reading and comprehension disorders or impairments.
> Additionally, there are many resources out there, and subject matter
> expertise specific to that topic, that can help us define what we mean by
> Plain Language (and we've got some of that expertise in the Silver WG
> already), but how do you *test* for that requirement? Can "plain language"
> be measured? How do you know when you have succeeded and when you have
> failed? Why did you fail, and how do you remediate that failure? What is
> the relationship between the content and the intended audience? A web site
> dedicated to macrobiology (https://quizlet.com/subject/macrobiology/)
> will at some level not be in "plain language" due to the subject matter,
> yet universities in the US must be WCAG 2.0 (Section 508) compliant, so now
> what? What are the requirements when you layer in internationalization
> issues? (I'd be curious to hear form our colleague Makoto what plain
> language means in the context of Japanese content...)
>
> I know from prior discussions inside the Silver TF that we will on
> occasion spend considerable time word-smithing particular sentences and
> information blocks, and where we end up with a consensus after multiple
> rounds of "fine-tuning" in real-time, because one of the goals for Silver
> is that the requirements be written in "Plain Language". That works when
> there are half-dozen SMEs on a conference call, but how do you scale that
> up? How do Fortune 500 companies, with literally hundreds (if not
> thousands) of content contributors involved in all facets of their web
> presence, consistently meet that goal? And how do internal as well as
> third-party entities test that with enough consistency that evaluation
> results will be (relatively) equal?
>
> WCAG has tried in the past to address this need (SC 3.1.5 Reading Level -
> AAA), but even then, we're told that reading level is not directly
> connected to Plain Language, and even the existing AAA SC we have is
> insufficient. I can accept that explanation, but what then is the solution?
>
> I don't have the answer, but I have some ideas. Glenda's proposal hit the
> meat of those ideas: that we define a methodology for evaluation that can
> be applied at scale. Even that won't be 'perfect', but I believe it would
> get us closer to the real goal (even if it ultimately fails in achieve the
> goal 100%).
>
> Hopefully you will be in attendance during the upcoming F2F meetings at
> CSUN, and I'd love to sit and discuss this further. I believe I want the
> same goals as you do, but how we get there will require a lot of thought,
> discussion and a fair bit of give-and-take along the way.
>
> JF
>
> On Thu, Mar 7, 2019 at 6:25 PM Delisi, Jennie (MNIT) <
> jennie.delisi@state.mn.us> wrote:
>
>> John,
>>
>> First, my apologies if my choice of phrasing sounded antagonistic. That
>> was not the intent. The conversation the COGA members had that day did not
>> include a feeling that people were specifically trying to exclude the needs
>> of the group, or that they were trying to pit one group against the other.
>> My poor choice of words did not properly communicate the issue, and I am
>> sorry. The group had identified several possible future success criteria
>> best addressed through manual testing, and testing that may take a bit of
>> time depending on the content. There had been discussion about other
>> success criteria already in place, but in no way were they upset that those
>> had been included. I will choose my words more carefully in the future.
>>
>>
>> Thank you for your comments about the "time element" and specific
>> testing methodologies for manually testing. I'm hoping more of the COGA
>> members will have time to read these comments in the next day or two, and
>> be able to respond as well.
>>
>>
>> Jennie
>>
>>
>> *Jennie Delisi*
>>
>> Accessibility Analyst | Office of Accessibility
>>
>> *Minnesota IT Services* | *Partners in Performance | *mn.gov/mnit
>>
>> 658 Cedar Street | Saint Paul, MN 55155
>> jennie.delisi@state.mn.us | O: 651-201-1135
>> ------------------------------
>> *From:* John Foliot <john.foliot@deque.com>
>> *Sent:* Thursday, March 7, 2019 4:08:35 PM
>> *To:* Chuck Adams
>> *Cc:* Glenda Sims; Delisi, Jennie (MNIT); Alastair Campbell;
>> lisa.seeman; COGA TF; Silver TF; Andrew Kirkpatrick
>> *Subject:* Re: WCAG 2.2 acceptance criteria
>>
>> So... I *do not* want to be taken out of context here, but a few
>> comments:
>>
>> One example we discussed was the current testing required to ensure that
>> the appropriate alt text is assigned for each image used on a page. 1-2
>> images on a page, not a big deal to test.
>>
>>
>> This is actually more nuanced, because the Success Criteria does not call
>> for "appropriate", it demands "equivalent purpose" which may not always be
>> the same. <ing src="" alt="sunset"> would pass the SC as written, even
>> though most of us instinctively know that the alt text there is "weak" (and
>> further, some might argue, warranting a longer textual description). *But
>> it meets the legal requirement.* Facebook's AI will often provide an alt
>> text "may include two people in front of a car" [sic], which again isn't
>> great alt text, but it *does* meet the minimum bar. (And while I never
>> advocate for just the minimum bar, I am pragmatic enough to realize that
>> sometimes that's the best you're gonna get.)
>>
>>
>> But, on a catalogue page, it could be significant.
>>
>>
>> Maybe, maybe not. I could also envision a code block for that catalog
>> page that looked something like this: <img src="" alt="Photo:
>> %item_name%"> <h3>%item_name%</h3>, where the value of %item_name%
>> would, in both instances, be populated from a data-base. Again, I'm not
>> *advocating* for that, I'm suggesting it is a reasonable solution in some
>> scenarios, and there the test could be as simple as looking at the source
>> code external to the data-base (or manually checking 3 images to ensure the
>> pattern is consistent, and then moving on)
>>
>>
>> The question came down to the concept that there may be manual testing
>> that (at this time) may be the only way to truly ensure a barrier is not
>> met by individuals with cognitive disabilities.
>>
>>
>> Sure, but as the requirements become more sophisticated, a specific
>> testing methodology must also be articulated and put into place: we can't
>> just toss requirements over the wall and hope everyone will figure it out
>> on their own. The Silver TF have discussed this at some length already (and
>> AFAIK not yet come up with a definitive "solution").
>>
>> From a matter of equality standpoint, why would the testing to address
>> the needs for one group be ok if it takes a lot of time, because they got
>> in on the creation of success criteria at the beginning of the process; but
>> for another group who’s needs were addressed more thoroughly later in the
>> development of success criteria, manual testing that may sometimes require
>> some time cannot be considered?
>>
>> Respectfully, I find that something of an antagonistic statement: this is
>> not singling out one group over another, it's about ensuring that what we
>> demand of content creators can be accurately and consistently verified for
>> compliance requirements. I would strongly caution that this discussion not
>> dive into one that pits one user group against the other: we're all here
>> for the same reasons. [*Flagging chairs*]
>>
>>
>> Meanwhile, Glenda wrote:
>>
>> To something like this:
>>
>>    - Be feasibly testable in a "reasonable amount of time" through
>>    automated or manual processes prior to Candidate Recommendation
>>    stage.  Examples include:
>>       - Automated - an automated testing tool exists that quickly and
>>       accurately determines if the criteria is met or not.
>>       - Assisted - a software tool exists that makes it more efficient
>>       for a tester to accurately determines if the criteria is met or
>>       not.
>>       - Manual - a manual process exists that makes it possible for a
>>       tester to accurately determines if the criteria is met or not.
>>
>> note:  "reasonable amount of time" can be determined by a call for
>> consensus.
>>
>> I'd actually leave the time element on the cutting-room floor: a)
>> personally I don't think we'd ever find that magic number, and b) I vaguely
>> recall a SC that speaks about "Timing Adjustable" <grin>, which to
>> paraphrase, effectively states that we shouldn't be locking people into
>> specific time-frames, that they can "adjust" that timing to meet their
>> individual needs. I would think that this would be of particular interest
>> to the Coga TF, as I suspect this is a real issue for many of those in that
>> user-group.
>>
>> I think what is far more important (I'd go as far as "Critical") is that
>> we produce, in conjunction with any SC that requires manual testing, a
>> specific testing methodology - a 'script' as it were - on how to
>> consistently test a component on the page, with clear and unambiguous
>> 'markers' on what is sufficient versus what is not. It's the methodology
>> piece that is critical, not the time it takes to do it (for example, the
>> *only* way to accurately determine if Audio Description is "correct"
>> today is to watch the entire video with Audio Description turned on -
>> whether that video is 3 minutes or 30 minutes or 300 minutes...)
>>
>> Minus the time reference however, +1 to Glenda's suggestion.
>>
>> JF
>>
>>
>> On Thu, Mar 7, 2019 at 3:31 PM Chuck Adams <charles.adams@oracle.com>
>> wrote:
>>
>> +1 Chuck
>>
>>
>>
>> *From:* Glenda Sims <glenda.sims@deque.com>
>> *Sent:* Thursday, March 7, 2019 2:03 PM
>> *To:* Delisi, Jennie (MNIT) <jennie.delisi@state.mn.us>
>> *Cc:* John Foliot <john.foliot@deque.com>; Alastair Campbell <
>> acampbell@nomensa.com>; lisa.seeman@zoho.com; COGA TF <
>> public-cognitive-a11y-tf@w3.org>; Silver TF <public-silver@w3.org>
>> *Subject:* Re: WCAG 2.2 acceptance criteria
>>
>>
>>
>> Goodwitch magically appears after being MIA for weeks to say:
>>
>>
>>
>> I suggest we clarify this bullet a bit more.  I think the example is a
>> useful example, but it isn't the only way to be "feasibly testable".  And
>> the way the sentence is written, it is hard to parse/process.  So what if
>> we changed from this:
>>
>>    - Be feasibly testable through automated or manual processes, i.e.
>>    take a few minutes per page with tools available prior to Candidate
>>    Recommendation stage.
>>
>> To something like this:
>>
>>    - Be feasibly testable in a "reasonable amount of time" through
>>    automated or manual processes prior to Candidate Recommendation stage.
>>    Examples include:
>>
>>
>>    - Automated - an automated testing tool exists that quickly and
>>       accurately determines if the criteria is met or not.
>>       - Assisted - a software tool exists that makes it more efficient
>>       for a tester to accurately determines if the criteria is met or
>>       not.
>>       - Manual - a manual process exists that makes it possible for a
>>       tester to accurately determines if the criteria is met or not.
>>
>> note:  "reasonable amount of time" can be determined by a call for
>> consensus.
>>
>>
>>
>> I'd suggest that if we pursue this "reasonable amount of time"
>> angle...that it be based on "reasonable amount of time" to test an ELEMENT
>> (not a page).  I think the variance in amount of time to test a page (when
>> pages can endlessly scroll) will make it impossible to come up with a
>> "reasonable amount of time" per page.
>>
>>
>>
>> I'm not in favor of leaving the requirement as it is currently drafted at
>> https://www.w3.org/WAI/GL/wiki/WCAG_2.2_Success_criterion_acceptance_requirements
>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.w3.org_WAI_GL_wiki_WCAG-5F2.2-5FSuccess-5Fcriterion-5Facceptance-5Frequirements%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Db-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c%26m%3D_p7Yxrl6Zp2sk72o5dwgmlwhjQ4eLo4fUWPVLEoAbk0%26s%3D5ef2UFktuiL-eTBWN_T3f0qUokZodp6f36XFMELbhbU%26e%3D&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933518961524&sdata=8PlmTNDzEb55rcFrHJGjD%2FXZip3sOByLDSXl1EfnxLo%3D&reserved=0>
>>
>>
>>
>>
>> G
>>
>>
>>
>> *glenda sims* <glenda.sims@deque.com>, cpacc
>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.accessibilityassociation.org_certification%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Db-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c%26m%3D_p7Yxrl6Zp2sk72o5dwgmlwhjQ4eLo4fUWPVLEoAbk0%26s%3D9o5lmzpfCNSt1f4YcOrQ9SYxuekoXeU2JQrstNBegME%26e%3D&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933518961524&sdata=vDqk6JIcq9%2FPTyU9Qfe5DVmrjtfc6fgmvgbHEV7TpAM%3D&reserved=0>
>>  | team a11y lead | 512.963.3773
>>
>>
>>
>>         deque systems
>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.deque.com%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Db-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c%26m%3D_p7Yxrl6Zp2sk72o5dwgmlwhjQ4eLo4fUWPVLEoAbk0%26s%3DAOB6VeDCie4SvizdBULO7MzT1sYorNafNsRlwX7_YEo%26e%3D&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933518971533&sdata=lJGN6NIWJ4PkD0Le1o1Mdnj7ikhAZofBE8P9cxfjXT4%3D&reserved=0>
>>   accessibility for good
>>
>>
>>
>>
>>
>> On Thu, Mar 7, 2019 at 1:31 PM Delisi, Jennie (MNIT) <
>> jennie.delisi@state.mn.us> wrote:
>>
>> Hello,
>>
>> Part of the concerns the COGA group discussed was that manual tests are
>> often required, and the variety of time required to test different pages
>> can vary greatly, depending on the content of that page.
>>
>>
>>
>> One example we discussed was the current testing required to ensure that
>> the appropriate alt text is assigned for each image used on a page. 1-2
>> images on a page, not a big deal to test. But, on a catalogue page, it
>> could be significant.
>>
>> The question came down to the concept that there may be manual testing
>> that (at this time) may be the only way to truly ensure a barrier is not
>> met by individuals with cognitive disabilities.
>>
>>
>>
>> I, too, work in an environment where a lot of testing occurs every day.
>> And, we have to hold contractors, vendors, and employees to standards that
>> can be measured. We need to be able to provide detailed and consistent
>> feedback when a failure of a success criteria has been noted. The time
>> taken to complete testing is definitely important. But, consideration of
>> barriers is the whole goal, right?
>>
>>
>>
>> From a matter of equality standpoint, why would the testing to address
>> the needs for one group be ok if it takes a lot of time, because they got
>> in on the creation of success criteria at the beginning of the process; but
>> for another group who’s needs were addressed more thoroughly later in the
>> development of success criteria, manual testing that may sometimes require
>> some time cannot be considered?
>>
>>
>>
>> I would like to propose that the language about the time it takes to
>> complete a test have an exception process, or propose a rewording of the
>> time component, so that the barriers experienced by this group of
>> individuals with disabilities receives fair consideration in this process.
>>
>>
>>
>> Jennie
>>
>>
>>
>> *Jennie Delisi, MA, CPWA*
>>
>> Accessibility Analyst | Office of Accessibility
>>
>> *Minnesota IT Services* |* Partners in Performance*
>>
>> 658 Cedar Street
>>
>> St. Paul, MN 55155
>>
>> O: 651-201-1135
>>
>> *Information Technology for Minnesota Government* | mn.gov/mnit
>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__mn.gov_mnit%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Db-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c%26m%3D_p7Yxrl6Zp2sk72o5dwgmlwhjQ4eLo4fUWPVLEoAbk0%26s%3D_LFhqvlrxsO3lXWJLlfp_27jFLhINYqTNbloiIO7Fuk%26e%3D&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933518981538&sdata=c61hAotUeheW845gPRfveq%2BBgQKjKs3Fv9WDJmXoS7Y%3D&reserved=0>
>>
>> [image: Minnesota IT Services Logo]
>>
>> [image: Facebook logo]
>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.facebook.com_MN.ITServices%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Db-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c%26m%3D_p7Yxrl6Zp2sk72o5dwgmlwhjQ4eLo4fUWPVLEoAbk0%26s%3DYvE-iUe2YSCmKu-16UikG2dQBqGSAzbXuMtLtuLpvt8%26e%3D&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933518981538&sdata=GZF9TSKzySF%2BsWlldpBFQZVjWRt%2FUCamMFQjOwTmj7Y%3D&reserved=0>[image:
>> LinkedIn logo]
>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.linkedin.com_company_mn-2Dit-2Dservices%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Db-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c%26m%3D_p7Yxrl6Zp2sk72o5dwgmlwhjQ4eLo4fUWPVLEoAbk0%26s%3DRK5dztyDuf9FrOqeASJlnJCg223LbPm8cHpkQHow7co%26e%3D&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933518991547&sdata=YLdbJw5aOUXZ0PrSxtRw9w6s%2FpO30vIdEVmJFCCfj1Y%3D&reserved=0>[image:
>> Twitter logo]
>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__twitter.com_mnit-5Fservices%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Db-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c%26m%3D_p7Yxrl6Zp2sk72o5dwgmlwhjQ4eLo4fUWPVLEoAbk0%26s%3DrcsHJ6yQ3mOK0YLis1zBI7MepoVIPPbUJP_8TCpirLs%26e%3D&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933518991547&sdata=QOW%2BmVKvlIIfIV0lP0gFmuJa3Ng9x1NLVrOOkdUIVxo%3D&reserved=0>
>>
>>
>>
>>
>>
>>
>>
>> *From:* John Foliot <john.foliot@deque.com>
>> *Sent:* Thursday, March 7, 2019 11:26 AM
>> *To:* Alastair Campbell <acampbell@nomensa.com>
>> *Cc:* lisa.seeman@zoho.com; Delisi, Jennie (MNIT) <
>> jennie.delisi@state.mn.us>; COGA TF <public-cognitive-a11y-tf@w3.org>;
>> Silver TF <public-silver@w3.org>
>> *Subject:* Re: WCAG 2.2 acceptance criteria
>>
>>
>>
>> Hi All,
>>
>>
>>
>> To perhaps also put a finer distinction on it... W3C Process mandates two
>> independent implementations of whatever new technology is being proposed -
>> a testing activity we actually did last spring during CSUN for the 2.1
>> Success Criteria (where, for SC 1.3.6 @ AAA we actually used the
>> implementations that Lisa had pointed us to). Those implementations may or
>> may not also serve as a 'testing tool', but as the Silver discussion
>> continues, a repeatable testing methodology will need to surface for each
>> new requirement, whether that is via a tool (mechanical tests - see: ACT
>> TF), or via a 'cognitive walk-though' or similar methodology (a process
>> still to be fully defined in Silver).
>>
>>
>>
>> At the end of the day, while it is true that our primary audience is and
>> will always be users with disabilities (of all stripes and forms), a second
>> important consideration is compliance requirements mandated by legislation.
>> To clear that hurdle, we will need to ensure that both implementers and
>> consumers have a baseline measurable & impartial (non-subjective) "test",
>> so that entities can then claim conformance based upon the outcome of said
>> test.
>>
>>
>>
>> JF
>>
>>
>>
>> On Thu, Mar 7, 2019 at 10:52 AM Alastair Campbell <acampbell@nomensa.com>
>> wrote:
>>
>> Hi Lisa,
>>
>>
>>
>> > To meet new user needs we may need new tools and reviews may need to
>> acquire new skills and knowledge.
>>
>>
>>
>> Which is fine, perhaps we can clarify that it means available at the time
>> of publication?
>>
>>
>>
>> New tools, especially if they “take a day” from a programmer would need
>> to be available at the time of publication, for the reasons I outlined in
>> the last email.
>>
>>
>>
>>
>>
>> > Also new tools will come as soon as we know a SC will be accepted. in
>> other word at CR. With WCAGs current history it will not come before then.
>>
>>
>>
>> Can you point to a previous example? I.e. where a tool that didn’t exist
>> was required to meet an SC wasn’t available until after CR?
>>
>> The closest I can think of is ARIA in WCAG 2.0, but it wasn’t actually
>> required to meet the SCs.
>>
>>
>>
>> It is very difficult to deal something in CR which then has to be pulled
>> because no one has created a tool, the whole timeline goes back a step. The
>> way the W3C prefers to work is to have working prototypes/code created
>> prior to specs. This has been a hard-learned approach [1].
>>
>>
>>
>> I suggest that if an SC needs a tool, we work up the SC template and go
>> through the initial process. That could be accepted on the condition that a
>> tool will be available. If it does not become available then the SC will be
>> removed before CR.
>>
>>
>>
>> It would also help to put those SC(s) first so people have more time to
>> work on the tools, I’ll make a note of that.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> 1] Accessibility example for what should be a ‘simple’ thing, the naming
>> algorithm.
>>
>>
>> https://www.linkedin.com/pulse/future-accname-spec-planning-strategy-functional-using-garaventa/
>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__gcc01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.linkedin.com-252Fpulse-252Ffuture-2Daccname-2Dspec-2Dplanning-2Dstrategy-2Dfunctional-2Dusing-2Dgaraventa-252F-26data-3D02-257C01-257Cjennie.delisi-2540state.mn.us-257C2a94ca2523bb46a0bdd208d6a321fd94-257Ceb14b04624c445198f26b89c2159828c-257C0-257C0-257C636875763714627907-26sdata-3DVCYgFIjR5CMjFxunizRlfRp8QYNbGpWZR8Sb6OmhcQI-253D-26reserved-3D0%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Db-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c%26m%3D_p7Yxrl6Zp2sk72o5dwgmlwhjQ4eLo4fUWPVLEoAbk0%26s%3DfQvWalvG5VAStfZ7Pmso1gyaTqOJ_sivl3M1isFCcBU%26e%3D&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933519001548&sdata=qdCq8Qf%2FC76IcV%2FlXsfr0R8C1I3fbkUtdZcwpq4iD30%3D&reserved=0>
>>
>>
>>
>>
>> --
>>
>> *​**John Foliot* | Principal Accessibility Strategist | W3C AC
>> Representative
>> Deque Systems - Accessibility for Good
>> deque.com
>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__gcc01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fdeque.com-252F-26data-3D02-257C01-257Cjennie.delisi-2540state.mn.us-257C2a94ca2523bb46a0bdd208d6a321fd94-257Ceb14b04624c445198f26b89c2159828c-257C0-257C0-257C636875763714637908-26sdata-3DGG0O3iMQp-252F8PHf6p8EWzegAcg-252FBpQuuSttIJLwi6EbA-253D-26reserved-3D0%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Db-9TIC95K-nLEKIDibNXAN_FKV-iXhLlAW2Zc3ebV_c%26m%3D_p7Yxrl6Zp2sk72o5dwgmlwhjQ4eLo4fUWPVLEoAbk0%26s%3DHvm23HBHHOyFc84ojLoyEOH_dH9_6VudfqT7rEX1dGM%26e%3D&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933519011562&sdata=aYb06tz28T18LPmPZZCltAsSWbqyiwL%2BKZbXeeZKkgU%3D&reserved=0>
>>
>>
>>
>>
>>
>> --
>> *​John Foliot* | Principal Accessibility Strategist | W3C AC
>> Representative
>> Deque Systems - Accessibility for Good
>> deque.com
>> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdeque.com%2F&data=02%7C01%7Cjennie.delisi%40state.mn.us%7Ceb313779e8eb41e52f7608d6a34985ba%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636875933519011562&sdata=vm7joHaJtLwdQX8bz6RQYy2Zh2DVjwKrotasZaJQvPw%3D&reserved=0>
>>
>>
>
> --
> *​John Foliot* | Principal Accessibility Strategist | W3C AC
> Representative
> Deque Systems - Accessibility for Good
> deque.com
>
>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com


image001.png
(image/png attachment: image001.png)

image002.png
(image/png attachment: image002.png)

image003.png
(image/png attachment: image003.png)

image004.png
(image/png attachment: image004.png)

Received on Friday, 8 March 2019 01:24:55 UTC

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2019 01:24:56 UTC