- From: EA Draffan <ead@ecs.soton.ac.uk>
- Date: Tue, 14 Jan 2020 13:08:30 +0000
- To: Steve Lee <stevelee@w3.org>, "public-cognitive-a11y-tf@w3.org" <public-cognitive-a11y-tf@w3.org>
+ 1 to Steve and Abi's concerns and my main worry is the complexity of all this not just the personalisation aspect and definitely consistency across pages and within web applications. I have been working with students on a project to try to automate more WCAG checks and these are all becoming harder by the day with an increasing number requiring manual input. For those of us who are not coders and have different roles (Not ARIA!) it means we depend on easy to follow guidelines. Sorry, but I think this needs a bit more clarity before moving on. Best wishes E.A. Mrs E.A. Draffan WAIS, ECS , University of Southampton Mobile +44 (0)7976 289103 http://access.ecs.soton.ac.uk -----Original Message----- From: Steve Lee [mailto:stevelee@w3.org] Sent: 14 January 2020 12:36 To: public-cognitive-a11y-tf@w3.org Subject: Re: Fwd: Re: WCAG 2.2 status - Visual indicators Hi Abi and thanks for your support of this SC. I'm not sure if this discussion is best taken to the AG list or if Rachael intended we discuss here first? Perhaps we can get agreement on our thoughts here before taking it to DavidM and the AG list? # Personalisation Like you I'm concerned about the SC relying on personalisation as it believe it will be the first to do so and the sort of issues you raise and more should be dealt with on a global basis across WCAG / Silver. There are an lot of issues and fine detail to be discussed and the personalisation TF work may not be developed enough yet. I think it best to remove the option that relies on personalisation for now. Also if we think it's important enough for an SC then surely browser implementations of standard controls must comply (via UAAG I assume). If we say it can be done via personalisation then we'd need to also state a default is provided and specify that anyway. TO be honest I'm not clear here on the relation ship between UAAG and WCAG for SCs that affect standard controls. The Current Visual Indicator SC proposal My concerns for the SC as it is are 1) It's unclear if is calling for all controls to have a indicator that distinguishes their purpose / behaviour or just a caret or border. 2) All the details should probably be in the understanding. This is how Keyboard Focus is handled without being prescriptive even though there are clear requirements for focus indicators. # Extending 3.2.4 Consistent Identification Your suggestion for an extension to 3.2.4 is interesting an I think could work. This does raise the issue of consistency as well as the need to highlight interactivity. That is an enhancement to my idea of just mirroring 2.4.7 Focus Visible which says 'the keyboard focus indicator" and does not consider that it varies visually across edit controls and buttons. Why did you say "within a page" and not "within a group of pages" like 3.2.4 does. I think that "page" is not good enough in general - we have other Cognitive Patterns calling for better consistency across pages. Interestingly 3.2.4 does not specify only Visual identification so I assume that was deliberate and Roles exposed to AT should also provide ' Consistent Identification' (obvious really). Or does WCAG leave Roles etc to the ARIA extension? I expect this would have to be a new SC as I doubt it is at all possible to refine an existing SC like 3.2.4 without breaking WCAG use. I expect is highly problematical. So in summary I be happy with your suggestion of a new SC that extends 3.2.4. I'm not sure the detail of contrast ratio should be in the SC as it's not for Focus which is equally important in my mind. I think this is better in the Understanding doc. Steve On 13/01/2020 21:31, James A. wrote: > Hi Steve > > Thanks for the summary on this one. I've been trying to support the development of this SC but can't join the AG calls due to timing. I share some example with the group from e-commerce sites where within the same shopping basket screen underline had been used for decoration and links while some icons had borders and some didn’t (of which some were interactive). This is quite typical in ecommerce sites and mobile apps I work on. > > I am concerned about going down the personalisation route as a very strong use case for visual indicators is for when users are using touch screens and therefore can't access tooltip or focus indicators. Users on tablets and phone browsers are less likely to have access to browser extensions and personalisation tools as well due to the nature of mobile ecosystems. > > One thought that had crossed my mind after reading the minutes of the last discussion was whether the SC could pivot to say a site must consistent visual indicators across all pages. This would lead it up to the site owner to decide what visual indicators were suitable but then have to use them consistently. So if an underline was used for links it couldn't be used for decoration. This would also be an extension of the existing 3.2.4 Consistent Identification AA success criteria which only deals with consistency across pages. > > The SC would then need to be something like > > "Visual indicators for active user interface component are consistent within a page. Where the visual indicator is a underline or an outline shape, the visual indicator has a contrast ratio of 3:1 with at least one adjacent color." > > This would not require a page to use visual indicators, but it would require them to be either used consistently on all interactive components or not at all. > > Best wishes > > Abi > > > -----Original Message----- > From: Steve Lee <stevelee@w3.org> > Sent: 13 January 2020 13:10 > To: public-cognitive-a11y-tf@w3.org > Subject: Re: Fwd: Re: WCAG 2.2 status - Visual indicators > > Thanks Rachael > > For those wanting to explore this more the SC proposal is here > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > .google.com%2Fdocument%2Fd%2F1WhZAbswvPHs7A3stfqM_ATsaBHPeGbHtARcmaKMc > k1U%2Fedit%3Fusp%3Dsharing&data=01%7C01%7Cead%40ecs.soton.ac.uk%7C > 44a5454caded4e90ba5208d798ee57ce%7C4a5378f929f44d3ebe89669d03ada9d8%7C > 0&sdata=w%2BMKvAEVRGgHJ%2BaoeZs09Lf1VxL6QIxYGZzqvPrREOg%3D&res > erved=0 > > and the text is > > "Each active user interface component provides a visual indicator which conveys its purpose. Where the visual indicator is a underline or an outline shape, the visual indicator has a contrast ratio of 3:1 with at least one adjacent color." > > This is certainly an important cognitive accessibility concern and > overlaps with [at least] these Patterns > > * Make it clear what are controls and how they should be used > * Support personalization of symbols and controls > > But as Alastair points out > > "we would have to be able > to answer the question “What is an appropriate visual indicator?” for any user-interface control." > > The tension is in ensuring we can define suitable indicators that are clear to everyone and yet allowing designers free choice that does not limit the required accessibility. If we are too prescriptive we will get a lot of push back and miss the intent. If we are to relaxed there is a danger the intent of the SC is subverted. Tricky. > > This question is somewhat an open ended and general across Patterns and cognitive SCs as they impact content design. Another broad question is what should be explicitly covered by an SC and what is best moved to personalisation, perhaps with an outline in SC itself. This uncertainty is raised in this SC text. > > These questions are likely to require significant discussion before distillation into an firm SC. We may need a lot of examples to ensure we have all cases covered if we cannot find a simple way to define for all controls. > > So unless we can easily answer Alastair's question or avoid it by invoking personalisation with some clearly defined limits for this SC I think the 2.2 timescales is going to be very hard to meet. > > Can anyone think of a way to resolve this? > > Steve > > On 13/01/2020 12:25, Rachael Montgomery wrote: >> Hello, >> >> I am sending this thread from the main WCAG mailing list because it >> relates to an SC that COGA has been supporting. The SC was not in the >> original set that we proposed but came up as an important gap during >> conversations. >> >> Please weigh in on Alistair’s point about moving it out of 2.2 for >> continued discussion. You can respond on the COGA list and I’ll >> aggregate responses. You can also respond directly on the AG email chain. >> >> Rachael >> >> >> ---------- Forwarded message ---------- >> *From:* Alastair Campbell <acampbell@nomensa.com> >> *Date:* Jan 13, 2020, 5:05 AM -0500 >> *To:* WCAG list <w3c-wai-gl@w3.org> >> *Cc:* Newton, Brooks (TR Product) <Brooks.Newton@thomsonreuters.com> >> *Subject:* Re: WCAG 2.2 status - Visual indicators >> >>> Hi Everyone, >>> >>> Brooks left a comment on the examples doc >>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd >>> o >>> cs.google.com%2Fdocument%2Fd%2F1fw8C-uHkPzI9IH4wWXdzjRmyfxTHNIYX3vk6 >>> 2 >>> Xsph4M%2Fedit%23heading%3Dh.ck57f2kxzytg&data=01%7C01%7Ca.james% >>> 4 >>> 0soton.ac.uk%7C5015e227fefe4d000c3e08d79829f495%7C4a5378f929f44d3ebe >>> 8 >>> 9669d03ada9d8%7C0&sdata=5ZXlSI2wkvESJY76xFGxlNSJ7LIK%2FD8SN2mPoa >>> L 76kU%3D&reserved=0> for visual indicators that I thought worth >>> discussing more widely: >>> >>>> “I don't like being forced to judge the efficacy of the visual indication, based on whether or not the control passes the current wording of the draft SC. I think we need to spend a lot more time discussing the issues at play with a broad range of interface controls that working group members identify as having problematic visual affordances. >>> >>>> Let's do that example gathering and review, before we create draft SC text to frame up the issues that surface through the review. I have already provided a number of very good examples, which I distributed to the working group through email. Having to re-enter those examples into this format which forces a false examination against draft SC text that was written without consideration of the examples in mind doesn't make sense to me.” >>> >>> If others feel similarly, then this is an indicator we should take >>> this SC out of the WCAG 2.2 slot. >>> >>> We do need examples, and this is a very worthwhile exercise, but if >>> we are not at the stage of refining SC wording then it is not an >>> exercise that will fit in the WCAG 2.2 timeline. >>> >>> In any guidelines scenario (including Silver) we would have to be >>> able to answer the question “What is an appropriate visual >>> indicator?” for any user-interface control. If we cannot reliably >>> answer that, then I suggest we put this as a research topic to >>> tackle after WCAG 2.2, probably on the Silver timeline: >>> >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >>> w >>> .w3.org%2FWAI%2FGL%2Fwiki%2FResearch_needed&data=01%7C01%7Ca.jam >>> e >>> s%40soton.ac.uk%7C5015e227fefe4d000c3e08d79829f495%7C4a5378f929f44d3 >>> e >>> be89669d03ada9d8%7C0&sdata=UGnNmoZZ%2FpabW9B0WVaVZIZ6470WkLRBrep >>> F >>> JEW35JI%3D&reserved=0 >>> >>> Kind regards, >>> >>> -Alastair >>> >
Received on Tuesday, 14 January 2020 13:08:38 UTC