- From: Mark Tanner <levelpress@gmail.com>
- Date: Sun, 11 Nov 2018 08:47:59 +0000
- To: tink@tink.uk
- Cc: david100@sympatico.ca, public-silver@w3.org
- Message-ID: <CA+j1zdRab_SbbHRChaTEWTee3ohrp8ohrX3AKaF+hYfcF6k=5w@mail.gmail.com>
The examples of the tab panel and real-time share prices don’t seem to address the specific question David raised. The question wasn’t whether there were examples of WCAG compliant designs which lacked usability, but whether there are examples of designs which would otherwise be usable but where adherence to WCAG made them unusable. It is a critical difference. Jeanne was quoting from the Silver research where “At least one (top-notch accessibility team) had to pull a feature that benefited people with disabilities because the organisation could not make it backward compatible to WCAG.” Are there concrete examples of this? Did the company with the real time share prices example actually have an implementation that was usable to screen reader users or people with cognitive processing disabilities but which wasn’t WCAG compliant? Or was it the case, because of the complexity of system, that they couldn’t get any kind of implementation (WCAG compliant or not) which benefited such users? The same with tab panels. Are there concrete examples of designs which are highly usable for screen reader users, but which contravene current WCAG guidelines or breach normative ARIA rules? If there are, it would be good to see and understand them as such instances would be critical in highlighting very concretely where improvements can be made in Silver. Mark Tanner On Sat, 10 Nov 2018 at 16:25, Léonie Watson <tink@tink.uk> wrote: > David wrote: > > > Is there an example of this that someone can provide? I know the > > opposite can be true where a site can comply with WCAG and still > > > be super hard to use ... but it usually happens when some > > complicated legacy application gets an order to conform to WCAG, so > > a > layer of ARIA etc. is spread over it like lipstick on a pig. I > > wouldn't say that that is WCAG's fault. > > I don't think it is helpful to use words like "fault", or (per your > related tweet) "blame". Wanting Silver to do things differently > shouldn't be regarded as a criticism of WCAG. I don't think anyone > thinks WCAG is perfect, but it's going to be really hard to try to do > better, if people feel like every suggestion is an implicit criticism of > what went before. > > In terms of concrete examples: > > A set of tabpanels can be created to conform with WCAG (using the ARIA > APG design pattern), yet we know that many users struggle to use them in > practice. > > I worked on a project for a financial institution, where the user > requirement was to monitor multiple share prices side-by-side in > real-time. Often the dataset would contain many tens of shares, with > each share being updated every minute or so (and not always in synchrony > with other shares). It was possible to present the data in a way that > conformed to WCAG, but not in a way that was usable to screen reader > users or people with cognitive processing disabilities. > > For converse examples: > > I can use a page where the headings are styled, but not marked up using > the appropriate elements. I either use alternative screen reader > shortcuts for navigation, or do what we used to do before heading > navigation was a thing, and read the content like a text document. > > It is quite possible for a document to fail parsing and still be > entirely usable with an AT. > > It is possible for someone with low vision to find content > readable/usable, even when the text does not meet the minimum colour > contrast threshold. > > If we ask whether a thing is conformant, and ask whether it is usable, > the answers will not always be the same. > > Léonie. > On 10/11/2018 14:06, David MacDonald wrote: > > > I've asked some people with examples of WCAG reducing accessibility > > to speak for themselves. > > > > I would love to see an example of this. > > > > > During the Silver research phase, we heard complaints from innovative > > organizations about the challenges of making accessible web applications > > meet WCAG requirements -- sometimes because of the WCAG definitions of > > "web", sometimes because of the WCAG orientation toward web "pages" in a > > web "application" environment, and sometimes because the WCAG > > requirements apply to old technology (static web) and it is > > increasingly difficult to apply them to new technology (like dynamic > > mobile web). > > > > If we are going to make a major change to the way we create a standard, > > I think we'll need more than an anonymous general statement with no > > actual details as a basis for that huge change. If the WCAG team doesn't > > have access to the specifics of the research it's going to be hard to > > determine the road ahead. > > > > I think there should be a 2 tier research approach, where when the > > Silver TF comes across something interesting and jarring like this, it > > could be referred to WCAG team members knowledgeable about the standard > > who investigate further and can determine whether it was one of the > > following: > > > > 1) a genuine flaw in WCAG that requires us to throw out the current > > model and find a different model, > > 2) a misunderstanding of WCAG which requires us to either make the > > requirements clearer, or to provide Education and Outreach resourse to > > fill the gap. > > 3) a misunderstanding of WCAG which is a result of not reading the > > Understanding Documents. > > > > For example, there was shrill public criticism by a leading > > accessibility trainer that companies were failing WCAG text sizing > > requirements. I contacted him quietly and asked if he read the > > understanding document... He said "why?", I said "the answer is there". > > The issue went away. I'm astonished at how few leading accessibility > > people have read the "Understanding" documents. Perhaps there is a > > problem in the way we presented them, but we thought a link from each SC > > to its understanding would be sufficient for anyone who wanted to > > understand it. The Silver tabbed approach and short description/long > > description might be better. > > > > But I think we need access to the research, the situations described, > > otherwise its pretty hard to admit the research as the basis for the new > > model. > > > > Cheers, > > David MacDonald > > > > *Can**Adapt**Solutions Inc.* > > > > Tel: 613-806-9005 > > > > LinkedIn > > <http://www.linkedin.com/in/davidmacdonald100> > > > > twitter.com/davidmacd <http://twitter.com/davidmacd> > > > > GitHub <https://github.com/DavidMacDonald> > > > > www.Can-Adapt.com <http://www.can-adapt.com/> > > > > / Adapting the web to *all* users/ > > > > / Including those with disabilities/ > > > > If you are not the intended recipient, please review our privacy policy > > <http://www.davidmacd.com/disclaimer.html> > > > > > > On Fri, Nov 9, 2018 at 3:37 PM Jeanne Spellman > > <jspellman@spellmanconsulting.com > > <mailto:jspellman@spellmanconsulting.com>> wrote: > > > > David, > > > > > Many of our audits include user testing with PWD and I depend on > > them. However, here are some of the fears I have in making user > > > testing with people with disabilities a requirement in WCAG.NEXT > > which might be referenced in law. > > > > I seriously doubt that we would make user testing a "requirement", > > because of all the reasons you said. We want to reward > > organizations that do more by giving them a higher score, not > > require them to do testing with people with disabilities. > > > > The question we are discussing is: when an automated or manual test > > from an auditor says that something fails, and testing with people > > with disabilities say that it is accessible, would the result from > > testing with people with disabilities be sufficient to say that it > > passes? And vice versa, if the traditional WCAG tests say that it > > passes, but people with disabilities say that it is inaccessible, > > can it claim Silver conformance? > > > > > Is there an example of this that someone can provide? I know the > > opposite can be true where a site can comply with WCAG and still > > > be super hard to use ... but it usually happens when some > > complicated legacy application gets an order to conform to WCAG, so > > a > layer of ARIA etc. is spread over it like lipstick on a pig. I > > wouldn't say that that is WCAG's fault. > > > > I've asked some people with examples of WCAG reducing accessibility > > to speak for themselves. I did not feel comfortable talking about > > them specifically in a public forum. I will say that they were NOT > > legacy systems with a sprinkling of ARIA. These were new, > > sophisticated web applications from top-notch accessibility teams > > that did a lot of user testing on accessibility features. At least > > one of them had to pull a feature that benefited people with > > disabilities because the organization could not make it > > backward-compatible to WCAG. During the Silver research phase, we > > heard complaints from innovative organizations about the challenges > > of making accessible web applications meet WCAG requirements -- > > sometimes because of the WCAG definitions of "web", sometimes > > because of the WCAG orientation toward web "pages" in a web > > "application" environment, and sometimes because the WCAG > > requirements apply to old technology (static web) and it is > > increasingly difficult to apply them to new technology (like dynamic > > mobile web). > > > > None of these examples are "WCAG's fault". I am certainly not > > trying to fault WCAG (if it comes across that way, I apologize). I > > think we have a responsibility with Silver to make sure we are doing > > our best to learn from WCAG 2.x and make Silver a giant leap forward > > -- the same way that WCAG 2 was a giant leap forward from WCAG 1.0. > > > > > > > > On 11/9/2018 2:05 PM, David MacDonald wrote: > >> > We heard the complaint from several large innovative companies > >> that they had to remove features that improved accessibility from > >> their applications because they didn't pass WCAG. > >> > >> Is there an example of this that someone can provide? I know the > >> opposite can be true where a site can comply with WCAG and still > >> be super hard to use ... but it usually happens when some > >> complicated legacyapplication gets an order to conform to WCAG, so > >> a layer of ARIA etc. is spread over it like lipstick on a pig.I > >> wouldn't say that that is WCAG's fault. > >> > >> Many of our audits include user testing with PWD and I depend on > >> them. However, here are some of the fears I have in making user > >> testing with people with disabilities a requirement in WCAG.NEXT > >> which might be referenced in law. > >> > >> 1) What is a user with a disability? The United Nations’ > >> Convention CRPD recognizes that “disability is an evolving concept > >> ... ” It is quite broad and many companies could claim their users > >> have a disability. Is someone going to be able to say "no those > >> users aren't qualified as people with disabilities". Are we going > >> to define what distinguishes a user with a disability from one who > >> doesn't have a disability? > >> 2) How does a 3rd party verify user testing with disabilities was > >> done? > >> 3) How is the quality measured? Some user testing is amazing and > >> makes all the difference, but legislated user testing sounds like > >> it may not result in very good quality. > >> 4) What happens with diverse responses from users? I've had one > >> expert screen reader user say they loved a particular function and > >> the other thought is was very difficult to use. > >> 5) A site has to be pretty mature to have user testing, > >> particularly if the user needs assistive technology, which means > >> its at the end of the development process, when the "cement is > hard". > >> 6) When is it enough user testing. How many pages? How much time? > >> > >> Cheers, > >> David MacDonald > >> > >> *Can**Adapt**Solutions Inc.* > >> > >> Tel: 613-806-9005 > >> > >> LinkedIn > >> <http://www.linkedin.com/in/davidmacdonald100> > >> > >> twitter.com/davidmacd <http://twitter.com/davidmacd> > >> > >> GitHub <https://github.com/DavidMacDonald> > >> > >> www.Can-Adapt.com <http://www.can-adapt.com/> > >> > >> / Adapting the web to *all* users/ > >> > >> /Including those with disabilities/ > >> > >> If you are not the intended recipient, please review our privacy > >> policy <http://www.davidmacd.com/disclaimer.html> > >> > >> > >> > >> On Fri, Nov 9, 2018 at 12:52 PM Léonie Watson <tink@tink.uk > >> <mailto:tink@tink.uk>> wrote: > >> > >> On 09/11/2018 17:35, Jennison Asuncion wrote: > >> > "We heard the complaint from several large innovative > >> companies that they had to remove features that improved > >> accessibility from their applications because they didn't pass > >> WCAG. That's a problem." > >> > >> +1 > >> > >> > > >> > I've often heard the phrase something like: "it complies, > >> but is it usable?" > >> > >> +1 > >> > >> > > >> > I think a key to Silver is that there is a level of > >> flexibility built-in to avoid both of these situations. > >> > >> +1 > >> > >> We've all seen things built to conform to WCAG, but which are > >> effectively unusable in the wild. > >> > >> We all advocate for users to be included throughout the > >> production > >> lifecycle, and for the usability of a thing to be considered a > >> defining > >> metric for success. > >> > >> We know that trying to document the requirements for each user > >> group > >> (and every variation within each group), simply isn't possible > >> - at > >> least, not to the extent that it can be distilled into a > >> usable set of > >> criteria/guidelines. > >> > >> Ultimately, we know that someone's ability to use a thing is > >> the real > >> acid test. > >> > >> So making usability a success metric for Silver not only seems > >> like the > >> logical thing to do, it also feels like the responsible thing > >> to do. > >> > >> Léonie. > >> > >> > > >> > > >> > Just my $0.02. > >> > Jennison > >> > > >> > > >> > > >> > ________________________________________ > >> > From: Jeanne Spellman [jspellman@spellmanconsulting.com > >> <mailto:jspellman@spellmanconsulting.com>] > >> > Sent: Friday, November 9, 2018 8:58 AM > >> > To: public-silver@w3.org <mailto:public-silver@w3.org> > >> > Subject: Re: Measurability in Silver > >> > > >> > Charles raises a very important issue: Can the qualitative > >> result be accepted as a measurable “pass”?. I am interested > >> in what you think about it. The example is link with no > >> underline that fails 1.4.1 Color Alone (a common design > >> pattern). Should Silver accept the results of a test with > >> users that found that a large percentage were able to identify > >> that it was a link, even though it was only defined by the > >> difference in color? Should that be a pass? > >> > > >> > Should tests with users be able to change the pass/fail of > >> the guidance? I think that's an important question that I > >> don't know the answer to yet. It gives an opportunity to for > >> companies with innovative responses to accessibility to prove > >> that their approach is more accessible, even if it is a > >> technical WCAG failure. We heard the complaint from several > >> large innovative companies that they had to remove features > >> that improved accessibility from their applications because > >> they didn't pass WCAG. That's a problem. Testing with users > >> with disabilities is a potential solution. I saw a > >> presentation at A11yBOS where the presenter showed some visual > >> designs that passed WCAG that were inaccessible. Testing with > >> users with disabilities could encourage companies to move away > >> from technical conformance to WCAG that is still inaccessible > >> and focus on what works for users. > >> > > >> > On the other hand, testing with users with disabilities can > >> be small datasets. They can be skewed toward one disability > >> or levels of expertise. Potentially, it might be easier to > >> game the system by who was being selected to participate in > >> the study. I have seen testing with people with disabilities > >> that provided very valuable accessibility information that > >> goes well beyond WCAG requirements. But do I want that to > >> override other conformance measures? I'm interested in some > >> new ideas that could help safeguard people from abusing the > >> system. > >> > > >> > > >> > > >> > > >> > > >> > On 11/7/2018 9:45 PM, David MacDonald wrote: > >> > I think most WCAG evaluators would not include transient > >> states that last a split second on inline links unless there > >> was some added value. > >> > > >> > On Tue, Nov 6, 2018 at 12:36 PM Hall, Charles (DET-MRM) > >> <Charles.Hall@mrm-mccann.com > >> <mailto:Charles.Hall@mrm-mccann.com><mailto: > Charles.Hall@mrm-mccann.com > >> <mailto:Charles.Hall@mrm-mccann.com>>> wrote: > >> > Following up on today’s conversation. > >> > > >> > RE: Testing as Pass/Fail versus Measurability > >> > > >> > All (or at least most) of the feedback, comments, and > >> opposition to a “measurable” approach seem to suggest or imply > >> that measurable means a scale – for example, a score of 1–5. > >> > > >> > Some thoughts based on a specific example: > >> > > >> > Success Criterion 1.4.1 Use of Color (Level A) > >> > Color is not used as the only visual means of conveying > >> information, indicating an action, prompting a response, or > >> distinguishing a visual element. > >> > > >> > Technique > >> > Situation A: If the color of particular words, backgrounds, > >> or other content is used to indicate information: > >> > G205: Including a text cue for colored form control labels > >> > Test > >> > For any content where color differences are used to convey > >> information: > >> > Check that the same information is available through text or > >> character cues. > >> > > >> > Interpretation > >> > “…text or character cues” here is intended to describe the > >> “visual means” as defined in the SC. So there is a simple pass > >> / fail test that “the same information” [as color] is visible. > >> > > >> > Hypothetical scenario > >> > Element is a link. The information and indication of action > >> is “this text is a link”. It is blue text within a line of > >> black text that is not a link. It is not underlined. Links are > >> stateful. There is only 1 of 5 states where there is no second > >> explicit visual means. In the default state, there is color > >> alone. In the focus, active, hover and visited states there > >> are additional visual affordances as well as the user agent > >> providing a pointer cursor where there is a pointing input > >> device. There is even a selected state, and a pseudo after > >> element that includes content of an icon that conveys the link > >> is external. > >> > > >> > So, “same information is available through text or character > >> cues” is true in 4 states, but not true in 1. Does this fail? > >> Under WCAG 1.4.1, it does. Under Silver, there may be other > >> options. As a scale (as suggested at the beginning), this > >> could earn a 4 of 5. However, that then requires an enumerated > >> mark such as ‘3 or higher’ to qualify as passing. There is > >> another option. What if the test question was “do people > >> understand from any visual cues that this text is a link?” > >> Then that question was answered by test participants that > >> included 60 people with a wide spectrum of visual abilities > >> and color deficiencies. If the result was 49 of 60 said “yes”, > >> and 8 of 60 said “yes, if” or “yes, when” and 3 said “no”, > >> there is clearly a new grey area or middle ground beyond > >> simply scoring on a scale. The qualitative result is that it > >> passed, while the quantitative result is that it scored high > >> enough to pass if the enumerated mark or threshold was 51%. > >> Can the qualitative result be accepted as a measurable “pass”? > >> > > >> > Cheers, > >> > > >> > > >> > Charles Hall // Senior UX Architect > >> > > >> > charles.hall@mrm-mccann.com > >> <mailto:charles.hall@mrm-mccann.com><mailto: > charles.hall@mrm-mccann.com > >> <mailto:charles.hall@mrm-mccann.com > >?subject=Note%20From%20Signature> > >> > w 248.203.8723 > >> > m 248.225.8179 > >> > 360 W Maple > >> Ave,< > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3D360%2BW%2BMaple%2BAve%2C%2BBirmingham%2BMI%2B48009%26entry%3Dgmail%26source%3Dg&data=02%7C01%7Cjasuncion%40linkedin.com%7C450a6dc8b219476a491008d64664cdec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773796110147851&sdata=HFtm78nsGk2bfj%2FYpklFlO2YWhEEU4JS9CSqNzk%2FsMs%3D&reserved=0 > > > >> Birmingham MI > >> 48009< > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3D360%2BW%2BMaple%2BAve%2C%2BBirmingham%2BMI%2B48009%26entry%3Dgmail%26source%3Dg&data=02%7C01%7Cjasuncion%40linkedin.com%7C450a6dc8b219476a491008d64664cdec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773796110147851&sdata=HFtm78nsGk2bfj%2FYpklFlO2YWhEEU4JS9CSqNzk%2FsMs%3D&reserved=0 > > > >> > mrm-mccann.com > >> <http://mrm-mccann.com>< > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mrm-mccann.com%2F&data=02%7C01%7Cjasuncion%40linkedin.com%7C450a6dc8b219476a491008d64664cdec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773796110157863&sdata=cYXcjAGCoIcVX3GLCoUL%2FF8NfBo5%2BJJjLM1mkHzApi8%3D&reserved=0 > > > >> > > >> > [MRM//McCann] > >> > Relationship Is Our Middle Name > >> > > >> > Ad Age B-to-B Agency of the Year, 2018 > >> > Ad Age Agency A-List 2016, 2017 > >> > Ad Age Creativity Innovators 2016, 2017 > >> > North American Agency of the Year, Cannes 2016 > >> > Leader in Gartner Magic Quadrant, 2017, 2018 > >> > > >> > > >> > This message contains information which may be confidential > >> and privileged. Unless you are the intended recipient (or > >> authorized to receive this message for the intended > >> recipient), you may not use, copy, disseminate or disclose to > >> anyone the message or any information contained in the > >> message. If you have received the message in error, please > >> advise the sender by reply e-mail, and delete the message. > >> Thank you very much. > >> > -- > >> > > >> > Cheers, > >> > David MacDonald > >> > > >> > > >> > > >> > CanAdapt Solutions Inc. > >> > > >> > Tel: 613-806-9005 > >> > > >> > LinkedIn > >> > > >> < > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7Cjasuncion%40linkedin.com%7C450a6dc8b219476a491008d64664cdec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773796110157863&sdata=n0ZxmQSCRIckSgkkt3Z%2BODhw%2FO4IkDRgBxO9eFfFi7c%3D&reserved=0 > > > >> > > >> > twitter.com/davidmacd > >> <http://twitter.com/davidmacd>< > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7Cjasuncion%40linkedin.com%7C450a6dc8b219476a491008d64664cdec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773796110167868&sdata=hZKCiAwYzCb0IyZM%2B9HTw1PGGDi%2Bwbdcr0SeeIvQ4Ns%3D&reserved=0 > > > >> > > >> > > >> GitHub< > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7Cjasuncion%40linkedin.com%7C450a6dc8b219476a491008d64664cdec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773796110177876&sdata=YGhUacLpKa1QeH2Sa5NXYs7wvA2t1%2FNe3WxCmTAMVwo%3D&reserved=0 > > > >> > > >> > www.Can-Adapt.com > >> <http://www.Can-Adapt.com>< > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7Cjasuncion%40linkedin.com%7C450a6dc8b219476a491008d64664cdec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773796110177876&sdata=tfPcq86ClXuVZxzz0ke%2BBeIcptobpNZL5QXKbD318FA%3D&reserved=0 > > > >> > > >> > > >> > > >> > Adapting the web to all users > >> > > >> > Including those with disabilities > >> > > >> > If you are not the intended recipient, please review our > >> privacy > >> policy< > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7Cjasuncion%40linkedin.com%7C450a6dc8b219476a491008d64664cdec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773796110187884&sdata=b4UPWdivbnEEuDkkLOeJJcxmmRHLwfMwHoXze9poOqA%3D&reserved=0 > > > >> > > >> > >> -- > >> @LeonieWatson @tink@toot.cafe Carpe diem > >> > > > > -- > @LeonieWatson @tink@toot.cafe Carpe diem > >
Received on Sunday, 11 November 2018 08:48:38 UTC