- From: L. David Baron <notifications@github.com>
- Date: Thu, 28 Mar 2019 17:38:52 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Friday, 29 March 2019 00:39:14 UTC
I think the basic justification for this feature is reasonable, but features that are designed to deny access to content need to be done particularly carefully. My biggest concern is that a feature whose purpose is to deny access to content needs to be handled particularly carefully so that it doesn't inadvertently deny access to content in cases that the authors of the content or the designers of the feature didn't think of. One aspect of this (and the one I've talked about so far in mozilla/standards-positions#109) is that it needs to be specified precisely enough to be interoperable, which includes having the definitions that it depends on (such as visual overflow) being specified precisely enough as well. This is needed to avoid harmful effects on browser competition. It's possible there are other concerns that need to be thought through. For example, interventions that modify the page to aid accessibility for users with poor vision or particular color requirements, or that modify the page for other reasons (say, text size inflation on mobile) could also change the results of this API and thus render content inaccessible. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/328#issuecomment-477821416
Received on Friday, 29 March 2019 00:39:14 UTC