- From: John Foliot <john.foliot@deque.com>
- Date: Thu, 7 Mar 2019 19:23:56 -0600
- 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>
- Message-ID: <CAKdCpxx3XTsjSHEuTFJnyfW7FiJp9ok6Ez2-7nJS2mV3Dc6HrA@mail.gmail.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
Attachments
- image/png attachment: image001.png
- image/png attachment: image002.png
- image/png attachment: image003.png
- image/png attachment: image004.png
Received on Friday, 8 March 2019 01:24:55 UTC