- From: Eric Eggert <ee@w3.org>
- Date: Tue, 8 Oct 2019 08:34:20 +0200
- To: Shadi Abou-Zahra <shadi@w3.org>
- Cc: "wai-eo-editors@w3.org" <wai-eo-editors@w3.org>
- Message-Id: <4B007C9D-2039-4EF6-B77D-E73CC5E14F77@w3.org>
> On 7. Oct 2019, at 21:36, Shadi Abou-Zahra <shadi@w3.org> wrote: > >> ### Issue 6 >> * Level: ED-high >> * Location: 7 >> * Current Wording: Tools can be integrated into different work >> environments. For example, into your web browser, content management system >> - CMS, code editor, or JavaScript framework. >> * Suggested Revision: Tools can be integrated into different work >> environments. For example, into your web browser, content management system >> - CMS, code editor, or your deploy process. >> * Rationale: This misses continuous integration methods that are available, >> I am unsure how one would build it into the JavaScrip framework. You can >> surely add it to the testing suite for your JavaScript framework, but that >> rings differently to me. > > I think the phrase "deploy process" is too jargony. Changed to "your JavaScript" (ie. dropped "framework"), which should be more accurate. From my point of view this makes it less accurate. You add the tests into the build or deploy process, not into the JavaScript or Framework. This gives the false impression that you have to ship more code to production to test for accessibility. I feel very strongly that we should underline that testing during deployment is a thing, as that is where most of automated non-accessibility testing happens. Not mentioning it means that watchers might get the impression that they have to have separate testing workflows for accessibility, leading to not adopting accessibility testing in a systematic way in the first place. 👋 Eric
Received on Tuesday, 8 October 2019 06:34:24 UTC