- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Sep 2019 02:50:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Display property value for visually hiding element while making available to assistive tech`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: Display property value for visually hiding element while making available to assistive tech<br>
<fantasai> astearns: brought up by TTML also<br>
<jcraig> https://github.com/w3c/csswg-drafts/issues/3708<br>
<fantasai> astearns: question is how to move forward on this capability<br>
<heycam> github: https://github.com/w3c/csswg-drafts/issues/3708<br>
<fantasai> AmeliaBR: The general use case is when you have text that adds a little extra information for assitive technology but either repeats something already visually on the page<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/560<br>
<fantasai> AmeliaBR: or is text that is already obvious because of other visual cuse<br>
<fantasai> s/cuse/cues/<br>
<fantasai> AmeliaBR: so don't want to print the text, but want available to a11y<br>
<fantasai> AmeliaBR: there are methods used by authors using absolute positioning or clip<br>
<fantasai> AmeliaBR: intentionally picked by authors because not currently used as cues to screen readers to hide the text<br>
<fantasai> AmeliaBR: so feature requests coming to ARIA and CSS<br>
<fantasai> AmeliaBR: is to have a simple one property one attribute way to do this<br>
<fantasai> AmeliaBR: there are ways in specs defined to do this<br>
<jcraig> Example of what AmeliaBR is referencing: <p>Read <a href=“#”>more <span class=“a11y”>About widgets</span></a></p><br>
<fantasai> AmeliaBR: there's aria-hidden=false, originally specified to do this<br>
<astearns> q?<br>
<fantasai> AmeliaBR: there is the 'speak' property in CSS Speech module<br>
<fantasai> https://www.w3.org/TR/css-speech/#speaking-props-speak<br>
<jcraig> hidden=true aria-hidden=false<br>
<fantasai> AmeliaBR: neither of these is implemented because in reality the visual display property has all sorts of side-effects in how elements are processed<br>
<jcraig> aria-hidden=true was problematic for a variety of reasons<br>
<fantasai> AmeliaBR: and saying 'display: none' or visually hidden but still available to AT<br>
<fantasai> AmeliaBR: has never happened in borwsers<br>
<jcraig> s/=true/=false/<br>
<fantasai> AmeliaBR: so feature request is for specific way to do things<br>
<fantasai> AmeliaBR: in ARIA yesterday had a talk about, is this really use case pattern we want to encourage by making it easier to do?<br>
<fantasai> AmeliaBR: visually-hidden styles can be misused by developers<br>
<fantasai> AmeliaBR: who are only thinking about visually-able vs. blind users<br>
<fantasai> AmeliaBR: missing a huge swath of people usign both AT and visual rendering<br>
<fantasai> AmeliaBR: so argument that this is a hacky approach for a reason, shouldn't make it easier<br>
<fantasai> AmeliaBR: but it is widely-used on the Web anyway, so argument for paving that cowpath<br>
<fantasai> AmeliaBR: my recommendation is to go ahead with this<br>
<fantasai> AmeliaBR: and do it in CSS<br>
<fantasai> AmeliaBR: because sometimes visually-hidden content depends on MQ<br>
<jcraig> q+ to remind the group that many (most?) screen reader users are not completely blind...<br>
<fantasai> AmeliaBR: e.g. button might have icon and text on big screen<br>
<fantasai> AmeliaBR: but on small screen only the icon<br>
<fantasai> AmeliaBR: but want AT to be able to see that text<br>
<florian> q+<br>
<astearns> ack jcraig<br>
<Zakim> jcraig, you wanted to remind the group that many (most?) screen reader users are not completely blind...<br>
<fantasai> jcraig: I think this is valuable and needed<br>
<fantasai> jcraig: but remind group that most screen reader users are not blind<br>
<fantasai> jcraig: there are a lot of low-vision users<br>
<fantasai> jcraig: ~ 1/5 are actually blind<br>
<nigel> q+ to point out that for text to describe media content the solution has to work in an ARIA live context<br>
<astearns> ack florian<br>
<fantasai> astearns: Amelia's comment was that this is a bad assumption some authors make, shouldn't encourage<br>
<tink> Q+<br>
<fantasai> florian: the reason why neither ARIA attr or speak has been easy to implement<br>
<fantasai> florian: is because AT works by reading plain text off the render tree<br>
<fantasai> florian: this is the reality today<br>
<fantasai> florian: can't ignore it<br>
<fantasai> florian: but causes many problems<br>
<fantasai> florian: exposing info to AT<br>
<fantasai> florian: I hope this is merely current reality<br>
<fantasai> florian: and not long-term goal we want to maintain<br>
<fantasai> florian: because in that case many limitations<br>
<fantasai> florian: there are many cases where we would want to work from DOM, not render tree<br>
<fantasai> florian: because render tree has lost information that's in the DOM\<br>
<fantasai> florian: I think we will see that problem in a number of use cases<br>
<fantasai> florian: I would like us to not abandon idea that aria / display proposals<br>
<astearns> ack nigel<br>
<Zakim> nigel, you wanted to point out that for text to describe media content the solution has to work in an ARIA live context<br>
<fantasai> florian: I hope this is taken as a current situation, not a design goal, because otherwise many things cannot be solved<br>
<fantasai> nigel: Some of the proposed solutions/hacks might not work for ARIA live environment<br>
<fantasai> nigel: for ? put forward this morning, want something that describes content in a video<br>
<jcraig> q+ to mention that WebKit was the one engine that implemented `hidden=false aria-hidden=true` and I can discuss some of the implementation details<br>
<fantasai> nigel: gets read out during playback of video<br>
<fantasai> nigel: want to use ARIA live region approach<br>
<fantasai> nigel: and have AT notice that<br>
<jcraig> s/live environment/live regions/<br>
<florian> s$that aria / display proposals$that aria / speak proposals$<br>
<fantasai> nigel: biggest gap we have is something that, following from florian's point, here is some text from render tree<br>
<fantasai> nigel: don't actually paint pixesl for it, leave layout alone<br>
<fantasai> nigel: atm visibility: hidden has effect that some screen readers don't read it out<br>
<fantasai> nigel: I would separate visibilty from display<br>
<fantasai> nigel: I would expect display: none to never feature in a display<br>
<fantasai> nigel: but visibilty is not rich enough<br>
<florian> fantasai: visibility hidden currently leave things in the layout tree<br>
<florian> fantasai: so they take up space<br>
<ZoeBijl> q+ to say that there are more assistive technologies than screen readers<br>
<florian> fantasai: we probably want variant that doesn't<br>
<fantasai> jcraig: technique used is positionign off-screen and clipping<br>
<fantasai> nigel: want something more proper<br>
<florian> s/variant/a variant/<br>
<fantasai> astearns: and more simple<br>
<astearns> ack tink<br>
<fantasai> tink: I'm really strongly in favor of this proposal<br>
<fantasai> tink: than existing methods, which cause alls orts of problems<br>
<fantasai> tink: can confirm that visibility: hidden does get hidden from screen readers<br>
<fantasai> tink: if we go ahead with an idea like this attribute<br>
<fantasai> tink: what will we do with tab focus?<br>
<fantasai> tink: techniqe that jcraig describes<br>
<fantasai> tink: tab focus disappears off screen<br>
<fantasai> tink: some renderers will screw up rendering as a result<br>
<fantasai> tink: would there be some mechanism to get around that problem?<br>
<fantasai> AmeliaBR: that's a very good argument for a proper bult-in feature<br>
<fantasai> AmeliaBR: then browser knows to override hiding and make things visible<br>
<fantasai> AmeliaBR: with current techniques, up to author to have a special focus rule<br>
<fantasai> AmeliaBR: to handle that case<br>
<fantasai> AmeliaBR: strong argument to have dedicated feature so browser knows why this style is being set, and to override<br>
<fantasai> tink: so if was focusable content hidden, once it got focus would become visible<br>
<fantasai> tink: makes visible, but if contents appear from off-screen, that would be quite disruptive<br>
<fantasai> tink: is there a possibility to do it the other way around, take things outside of focusability?<br>
<fantasai> AmeliaBR: that wouldn't help with skip links<br>
<fantasai> tink: screenreaders have much better ways to navigate content<br>
<fantasai> tink: skip links are mainly useful for sighted suers<br>
<fantasai> s/sighted suers/sighted keyboard users/<br>
<fantasai> florian: would be problem to make things visible without author expecting it<br>
<fantasai> florian: likely to break things<br>
<jamesn> q+<br>
<fantasai> florian: would rather make it not visible, invoke HTML inert behavior<br>
<fantasai> florian: author can pop things into visual space if they want<br>
<fantasai> AmeliaBR: or maybe two different values of a property, recognize different use cases<br>
<fantasai> AmeliaBR: standard skip link that should become visible<br>
<fantasai> AmeliaBR: and extra information for screen readers<br>
<jcraig> q?<br>
<jcraig> ack me<br>
<Zakim> jcraig, you wanted to mention that WebKit was the one engine that implemented `hidden=false aria-hidden=true` and I can discuss some of the implementation details<br>
<astearns> ack jcraig<br>
<fantasai> jcraig: couple techniques mentioned, one seemed reasonable was HTML hidden=false<br>
<fantasai> jcraig: aria-hidden=true<br>
<fantasai> jcraig: or reverse of that rather<br>
<nigel> q+ to reply<br>
<fantasai> jcraig: webkit was the only browser to implement<br>
<fantasai> jcraig: was very tricky, because webkit builds accessibiltiy tree off of render tree<br>
<fantasai> jcraig: this was after fork from blink, so blink doesn't have<br>
<fantasai> jcraig: firefox same thing<br>
<fantasai> jcraig: so very challenging<br>
<fantasai> jcraig: after noticing bugs<br>
<fantasai> jcraig: decided to only allow this if every ancestor above was displayed<br>
<fantasai> jcraig: so child node could be hidden, but not descendant<br>
<fantasai> jcraig: not sure that's the right path, but is the one available atm<br>
<fantasai> jcraig: technique in the ARIA spec, aria-hidden=false not recommended<br>
<astearns> ack nigel<br>
<Zakim> nigel, you wanted to reply<br>
<fantasai> jcraig: hidden=true aria-hidden=false<br>
<fantasai> nigel: interaction between attributes and CSS properties not clear in spec, and varies in implementations<br>
<fantasai> nigel: there some weird stuff going on there<br>
<fantasai> nigel: my conclusion was to ignore HTML hidden<br>
<fantasai> jcraig: on WebKit side, implementation was hidden=true { display: none; }<br>
<fantasai> Rossen__: Edge actually supports everything you said about computing aria and various permutations<br>
<fantasai> Rossen__: there is an effort that was in EdgeHTML<br>
<fantasai> Rossen__: have ongoing work in Chromium to add additional capabilities to handle that n Chromium-based browsers<br>
<fantasai> Rossen__: not sure where Mozilla is<br>
<fantasai> jcraig: no plans last I heard<br>
<astearns> ack ZoeBijl<br>
<Zakim> ZoeBijl, you wanted to say that there are more assistive technologies than screen readers<br>
<fantasai> ZoeBijl: Want to remidne veryone that there are more AT than just screenreaders that might be affected by this stuff<br>
<astearns> ack jamesn<br>
<fantasai> ?: displaying something ...<br>
<fantasai> ?: Issue of deliberately making things visible<br>
<astearns> s/?/jamesn/<br>
<fantasai> jamesn: another use case is when you have native HTML control that you do not want to display but you want to use all of the properties that you get for free<br>
<fantasai> jamesn: e.g. range control, can't increment/decrement unless native<br>
<fantasai> jamesn: but can't sytle it properly<br>
<fantasai> jamesn: so hide it, and display your own control over it<br>
<fantasai> jamesn: common authoring technique right now, because can't make controls accessible on moble<br>
<fantasai> jamesn: is one custom control for visual, and one hiden native control for interaction<br>
<fantasai> jamesn: hidden using very low opacity so stll there<br>
<fantasai> jamesn: you wnat it to not be inert in this case<br>
<nigel> scribe: nigel<br>
<nigel> fantasai: we've heard a lot of new info in this meeting<br>
<florian> fantasai: we've heard a lot of new information<br>
<nigel> .. next step is someone to draft a proposal for a new CSS property or value<br>
<nigel> .. probably a property<br>
<jcraig> display value?<br>
<nigel> .. that takes into account the use cases here and the various limitations<br>
<nigel> .. I haven't heard a proposal yet.<br>
<fantasai> astearns: https://github.com/w3c/csswg-drafts/issues/560<br>
<nigel> astearns: Is there a specific CSS spec for this?<br>
<nigel> s/spec/issue<br>
<nigel> fantasai: We definitely don't want to use the display property for this.<br>
<nigel> .. too many other effects.<br>
<nigel> .. There is an existing property in the speech module called speak<br>
<jcraig> q+<br>
<nigel> .. which was intended for this use case but it doesn't address the issues of the render tree and focusability<br>
<nigel> jcraig: I've evidence that it was never intended to address this<br>
<nigel> .. it's well specced for DAISY<br>
<fantasai> jcraig: css-speech is very well-specced for DAISY use case, not for screenreader<br>
<nigel> scribe: fantasai<br>
<astearns> ack jcraig<br>
<jcraig> ack me<br>
<fantasai> astearns: need a volunteer<br>
<fantasai> astearns: lacking a volunteer, keep the issue open and periodically ping people<br>
<fantasai> tink: can try to put words together but need someone on CSS side<br>
<fantasai> AmeliaBR: I can help<br>
<fantasai> ACTION: Amelia and tink to draft a proposal<br>
<trackbot> Created ACTION-883 - And tink to draft a proposal [on Amelia Bellamy-Royds - due 2019-09-24].<br>
<IanPouncey> I can also help.<br>
<fantasai> astearns: and bkardell_<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/560#issuecomment-532035887 using your GitHub account
Received on Tuesday, 17 September 2019 02:50:50 UTC