- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Thu, 16 Jul 2020 15:56:09 +0000
- To: "Newton, Brooks (TR Product)" <Brooks.Newton@thomsonreuters.com>
- CC: "WCAG list (w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org>
- Message-ID: <DB8PR09MB33395A8E1C4AA5DC1C6AFC81B97F0@DB8PR09MB3339.eurprd09.prod.outlook.com>
Hi Brooks, > I want to make it clear that I don't agree with the "Unobscured" exception that has been carved out of the AA Success Criterion ... Providing a pass for situations ... seems like an argument against the much of the intent of the Success Criteria - making it clear what the minimum visibility should be to make focus indicators perceivable to sighted users. (Chair hat off.) Initially I agreed with that perspective, when it was targeted at the focus indicator it acted as an exception. The tweak (which I think was successful) was to move the target of the bullet to the element which has focus, not the indicator. Remembering that 2.4.7 does not cover the scenario of sticky headers/footers (i.e. obscured focus indicators do not cause a failure), we have a couple of possible outcomes from this: 1. Add the bullet, and explain the context in the understanding. I.e. it is for temporary things like sticky footers. 2. Not add the bullet, and things like sticky footers are obscured but do not cause a failure. Personally, I was happy to do something about the sticky-content issue so long as it doesn't undermine other aspects of the SC. We had a pretty much unanimous agreement that we should do something about it if we could, so that's why we are here. > I said the same during a call a couple of weeks ago, as indicated in the June 30th AGWG meeting minutes<https://www.w3.org/2020/06/30-ag-minutes.html>. Indeed, although you didn't object to the addition in the last call on that (+0), presumably because the decision was laid out as above? > During the same meeting I made the suggestion ... to come up with some new markup that would make clear the role, properties, attributes, etc. of the sticky content. That's an interesting approach, but it doesn't help us at the moment as the timelines on that sort of update are generally quite long. Also, I'm not sure it would get traction as there already is a mechanism to tell the browser that there is sticky content, CSS scroll-padding: https://css-tricks.com/almanac/properties/s/scroll-padding/ However, the reason MichaelG (and I) wanted to use a "partially" approach is because it is not a 100% solvable problem in browsers. You can set a height to allow for the sticky content, but the height of the sticky content can vary (e.g. text-wrapping, text-spacing). As you cannot dynamically vary the height of the scroll-padding, this is not something the author can solve 100%. (At least, without some custom JavaScript, but everyone who said they used that approach had given up on it, it's fragile.) > a Success Criterion that's primarily about making sure focus is perceivable by setting clear, objective minimum standards. Indeed, I think the (mental) separation is between the focus indicator (bullets 1-3), and whether the entire element+indicator is partially obscured by other content (bullet 4). If you have met the first three bullets, you will have a clear indicator. I'm hoping that mitigates your concern? The update added to the understanding document is relatively brief: https://raw.githack.com/w3c/wcag/wcag22-focus-visible-enh-updates/understanding/22/focus-appearance-minimum.html#unobscured If you'd like to propose any updates, or perhaps create an advisory technique with scroll-padding, that would be very welcome. Kind regards, -Alastair PS. Regarding the regrets, I've just searched for that but can't find it, could you check it was sent? If it was, I must be missing some email for some reason.
Received on Thursday, 16 July 2020 15:56:26 UTC