W3C home > Mailing lists > Public > www-style@w3.org > December 2019

[CSSWG] Minutes Fukuoka F2F 2019-09-17 Part III: Joint Meeting with Accessibility Group

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 3 Dec 2019 18:13:40 -0500
Message-ID: <CADhPm3sEzuMc5xYzdYzKcKAiomM5WBUk4DK8dMJbQeBj_W9dnQ@mail.gmail.com>
To: www-style@w3.org
Cc: public-css-a11y@w3.org, public-apa@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Joint Meeting with Accessibility
--------------------------------

  - Many of the use cases bubbling up can be solved in CSS by creating
      a user stylesheet.

  - One open item is a request to add additional spacing between words
      / punctuation. This will be hard to solve in the browser since
      rules vary between languages and linguistic analysis is
      required, and also different users require different types of
      spacing. However CSS can provide rendering support for browser
      extensions that implement such a feature.

  - There are two volunteers to draft an Accessibility API
      specification. It will be sent around for review once a draft is
      prepared.

  - The 'speak' property isn't covering all the use cases that need to
      be handled for Issue #560 (Display property value for visually
      hiding element while making available to assistive tech).
  - The combination of hidden=true aria-hidden=false isn't implemented
      across all browsers and when WebKit implemented it they had
      difficulties since it builds accessibility tree off of render
      tree.
  - A small group will draft a proposal of a new property that covers
      these cases. tink, AmeliaBR, bkardell, and IanPouncey all
      offered to work on the draft.

  - RESOLVED: Remove section on animation and wontfix issue about
              paragraph about accessibility because no longer relevant
              (Issue #3870: Add accessibility section [to CSS
              Transforms 1])

===== FULL MINUTES BELOW =======

Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda

Scribe: fantasai

Joint Meeting with Accessibility
================================

Overview of user requirements
-----------------------------

  Janina: FYI but need support from CSS
  Janina: We have a lot of user requirements about using better for
          user style sheet things
  Janina: Controlling animations was a need, can do, wasn't aware but
          that's great
  Janina: But need to be able to control spacing between words and
          between punctuation
  Janina: Can be done on user side, I believe?
  Janina: Seems you have to be an expert user, invoke the things
  Janina: Make that more usable, would appreciate CSSWG support on that
  Janina: WCAG guidelines are quite regulatory
  Janina: help to get technological solutions sorted
  Janina: and built into browsers
  <AmeliaBR> (Better browser support for user style overrides would be
             wonderful, but yes, probably outside of our realm to
             specify.)

  Janina: Cognitive and learning disability and low-vision requirements
  Janina: Would it be reasonable to control flashing?
  florian: There was a long list of things you might want to control
           in your requirements
  florian: Not sure we have solution for every single one, but many
           are things that authors can control
  florian: and we do have notion of user style sheets
  florian: This is a notion, doesn't have to be a style sheet written
           in CSS by programmers
  florian: Perfectly OK for User Agent to have a UI that sets these
           rules
  florian: Cascade then says how the user prefs and author prefs
           interact
  florian: but usability of making such settings is a UA issue

  jcraig: For motion, have prefers-reduced-motion implemented across
          browses now
  jcraig: Media features and web pages can adapt to them
  jcraig: that seems to be solved wrt CSSWG, but usability can improve

  Janina: Audio, killing all sounds. Part of browser config
  jcraig: Want sounds on device but not pages?
  janina: bubbling up out of COGA (cognitive)
  florian: We don't generate sounds in CSS generally, so don't have a
           way to turn off
  myles: Desktop browsers have ability to shut off sounds per tab

  janina: spacing: interlinear, inter-word, punctuation
  jcraig: letter-spacing available since CSS2.1
  jcraig: Not easy for users to define, but outside scope of CSSWG to
          solve
  florian: Spacing after punctuation specifically is not something we
           can control on author and user side
  janina: Request to have more space around punctuation
  <tantek> sounds like a feature request
  fantasai: We do have word-spacing property, but nothing for spacing
            around punctuation
  janina: Can add?
  fantasai: Depends, do you want different spacing at end of sentence
            vs after abbreviation? We don't know where the end of the
            sentence is.
  florian: Spacing requirements are also quite dependent on language
  florian: Various conventions, requirements per language/
           writing-system
  florian: So hard to make that work globally
  fantasai: Feature we have are typographic mainly
  fantasai: A lot of the learning disabilities require -- I would
            require more spacing after phrases, or sentences, things
            that need linguistic analysis
  fantasai: it's a bit difficult to solve on the CSS side
  fantasai: but could be solved with CSS and a browser extension maybe
  <jcraig> Myles mentioned text-spacing: punctuation

  dauwhe: There's a weird property by Prince called text-replace, we
          can replace certain characters with e.g. space-punctuation
          sequence
  <dauwhe> prince-text-replace:
https://www.princexml.com/doc-refs/#prop-prince-text-replace

  Rossen: We have one issue remaining from TTML
  astearns: Will cover after

Accessibility API
-----------------

  janina: Next issue, we agreed to do an Accessibility API Mappings
          with CSS
  janina: Some people volunteered to edit
  janina: So will be sending a draft
  <jcraig> Zoe Bijl and Joanie Diggs
  janina: Joanie will bring a11y expertise
  janina: Zoe will bring CSS knowledge
  janina: Will specify how to standardize across OSes
  janina: Unless questions about that, move on to next issues

  jcraig: Had issue about dynamic text size, which is CSS issue 3708
  astearns: ok next issue...

Visually hiding element while making available to assistive tech
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/560

  astearns: Brought up by TTML also
  astearns: Question is how to move forward on this capability
  AmeliaBR: The general use case is when you have text that adds a
            little extra information for assistive technology but
            either repeats something already visually on the page
  AmeliaBR: or is text that is already obvious because of other visual
            cues
  AmeliaBR: so don't want to print the text, but want available to a11y
  AmeliaBR: There are methods used by authors using absolute
            positioning or clip
  AmeliaBR: intentionally picked by authors because not currently used
            as cues to screen readers to hide the text
  AmeliaBR: so feature requests coming to ARIA and CSS
  AmeliaBR: is to have a simple one property one attribute way to do
            this
  <jcraig> Example of what AmeliaBR is referencing:
           <p>Read <a href=“#”> more <span class=“a11y”>about
           widgets</span></a></p>

  AmeliaBR: There are ways in specs defined to do this
  AmeliaBR: There's aria-hidden=false, originally specified to do this
  AmeliaBR: There is the 'speak' property in CSS Speech module
  <fantasai> https://www.w3.org/TR/css-speech/#speaking-props-speak
  <jcraig> hidden=true aria-hidden=false
  <jcraig> aria-hidden=false was problematic for a variety of reasons
  AmeliaBR: Neither of these is implemented because in reality the
            visual display property has all sorts of side-effects in
            how elements are processed
  AmeliaBR: and saying 'display: none' or visually hidden but still
            available to AT
  AmeliaBR: has never happened in browsers
  AmeliaBR: so feature request is for specific way to do things
  AmeliaBR: In ARIA yesterday had a talk about, is this really use
            case pattern we want to encourage by making it easier to
            do?
  AmeliaBR: visually-hidden styles can be misused by developers
  AmeliaBR: who are only thinking about visually-able vs. blind users
  AmeliaBR: Missing a huge swath of people using both AT and visual
            rendering
  AmeliaBR: so argument that this is a hacky approach for a reason,
            shouldn't make it easier
  AmeliaBR: but it is widely-used on the Web anyway, so argument for
            paving that cowpath
  AmeliaBR: My recommendation is to go ahead with this
  AmeliaBR: and do it in CSS
  AmeliaBR: because sometimes visually-hidden content depends on MQ
  AmeliaBR: e.g. button might have icon and text on big screen
  AmeliaBR: but on small screen only the icon
  AmeliaBR: but want AT to be able to see that text
  <ZoeBijl> I think the request is to have a single property that
            allows us to visually hide something while keeping it
            exposed to the accessibility API. You can currently do
            this with some seven lines of CSS. But that is a very
            hacky way of doing it.

  jcraig: I think this is valuable and needed
  jcraig: but remind group that most screen reader users are not blind
  jcraig: There are a lot of low-vision users
  jcraig: ~ 1/5 are actually blind
  astearns: Amelia's comment was that this is a bad assumption some
            authors make, shouldn't encourage

  florian: The reason why neither ARIA attr or speak has been easy to
           implement
  florian: is because AT works by reading plain text off the render
           tree
  florian: This is the reality today.
  florian: Can't ignore it, but this causes many problems.
  florian: I hope this is merely current reality
  florian: and not long-term goal we want to maintain
  florian: because in that case many limitations
  florian: There are many cases where we would want to work from DOM,
           not render tree
  florian: because render tree has lost information that's in the DOM.
  florian: I think we will see that problem in a number of use cases
  florian: I would like us to not abandon idea that aria / speak
           proposals
  florian: I hope this is taken as a current situation, not a design
           goal, because otherwise many things cannot be solved

  nigel: Some of the proposed solutions/hacks might not work for ARIA
         live regions
  nigel: For ? put forward this morning, want something that describes
         content in a video
  nigel: gets read out during playback of video
  nigel: Want to use ARIA live region approach
  nigel: and have AT notice that
  nigel: Biggest gap we have is something that, following from
         florian's point, here is some text from render tree
  nigel: don't actually paint pixels for it, leave layout alone
  nigel: At the moment visibility: hidden has effect that some screen
         readers don't read it out
  nigel: I would separate visibility from display
  nigel: I would expect display: none to never feature in a display
  nigel: but visibility is not rich enough
  fantasai: visibility: hidden currently leave things in the layout
            tree
  fantasai: so they take up space
  fantasai: We probably want a variant that doesn't
  jcraig: Technique used is positioning off-screen and clipping
  nigel: Want something more proper
  astearns: and more simple

  tink: I'm really strongly in favor of this proposal
  tink: than existing methods, which cause all sorts of problems
  tink: Can confirm that visibility: hidden does get hidden from
        screen readers

  tink: If we go ahead with an idea like this attribute
  tink: what will we do with tab focus?
  tink: Technique that jcraig describes
  tink: tab focus disappears off screen
  tink: Some renderers will screw up rendering as a result
  tink: Would there be some mechanism to get around that problem?
  AmeliaBR: That's a very good argument for a proper built-in feature
  AmeliaBR: then browser knows to override hiding and make things
            visible
  AmeliaBR: With current techniques, up to author to have a special
            focus rule
  AmeliaBR: to handle that case
  AmeliaBR: Strong argument to have dedicated feature so browser knows
            why this style is being set, and to override
  tink: So if was focusable content hidden, once it got focus would
        become visible
  tink: Makes visible, but if contents appear from off-screen, that
        would be quite disruptive
  tink: Is there a possibility to do it the other way around, take
        things outside of focus-ability?
  AmeliaBR: That wouldn't help with skip links
  tink: screenreaders have much better ways to navigate content
  tink: Skip links are mainly useful for sighted keyboard users
  florian: Would be problem to make things visible without author
           expecting it
  florian: Likely to break things
  florian: Would rather make it not visible, invoke HTML inert behavior
  florian: author can pop things into visual space if they want
  AmeliaBR: Or maybe two different values of a property, recognize
            different use cases
  AmeliaBR: Standard skip link that should become visible
  AmeliaBR: and extra information for screen readers
  <bkardell> do we have examples of a CSS property that causes inert?

  jcraig: Couple techniques mentioned, one seemed reasonable was HTML
          hidden=false
  jcraig: aria-hidden=true
  jcraig: or reverse of that rather
  jcraig: webkit was the only browser to implement
  jcraig: Was very tricky, because webkit builds accessibility tree
          off of render tree
  jcraig: This was after fork from blink, so blink doesn't have
  jcraig: firefox same thing
  jcraig: so very challenging
  jcraig: After noticing bugs
  jcraig: decided to only allow this if every ancestor above was
          displayed
  jcraig: so child node could be hidden, but not descendant
  jcraig: Not sure that's the right path, but is the one available atm
  jcraig: Technique in the ARIA spec, aria-hidden=false not recommended
  jcraig: hidden=true aria-hidden=false

  nigel: Interaction between attributes and CSS properties not clear
         in spec, and varies in implementations
  nigel: there some weird stuff going on there
  nigel: My conclusion was to ignore HTML hidden
  jcraig: On WebKit side, implementation was hidden=true { display:
          none; }
  Rossen: Edge actually supports everything you said about computing
          aria and various permutations
  Rossen: there is an effort that was in EdgeHTML
  Rossen: Have ongoing work in Chromium to add additional capabilities
          to handle that in Chromium-based browsers
  Rossen: not sure where Mozilla is
  jcraig: No plans last I heard

  ZoeBijl: Want to remind everyone that there are more AT than just
           screenreaders that might be affected by this stuff

  jamesn: Displaying something ...
  jamesn: Issue of deliberately making things visible
  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
  jamesn: e.g. range control, can't increment/decrement unless native
  jamesn: but can't style it properly
  jamesn: so hide it, and display your own control over it
  jamesn: Common authoring technique right now, because can't make
          controls accessible on mobile
  jamesn: is one custom control for visual, and one hidden native
          control for interaction
  jamesn: Hidden using very low opacity so still there
  jamesn: you want it to not be inert in this case

  fantasai: We've heard a lot of new info in this meeting
  fantasai: Next step is someone to draft a proposal for a new CSS
            property or value
  fantasai: probably a property
  fantasai: that takes into account the use cases here and the various
            limitations
  <jcraig> display value?
  fantasai: I haven't heard a proposal yet.
  astearns: https://github.com/w3c/csswg-drafts/issues/560
  astearns: Is there a specific CSS issue for this?
  fantasai: We definitely don't want to use the display property for
            this.
  fantasai: Too many other effects.
  fantasai: There is an existing property in the speech module called
            speak
  fantasai: which was intended for this use case but it doesn't
            address the issues of the render tree and focus-ability
  jcraig: I've evidence that it was never intended to address this
  jcraig: It's well specced for DAISY
  jcraig: css-speech is very well-specced for DAISY use case, not for
          screenreader
  jcraig: ...
  <florian> jcraig I was not aware that there were dismissed feedback
            on the css-speech spec. That's unfortunate, maybe we
            should reopen and try and making it appropriate for both
            uses cases. I thought it was.
  * fantasai isn't aware of dismissed feedback either

  astearns: Need a volunteer
  astearns: Lacking a volunteer, keep the issue open and periodically
            ping people
  tink: Can try to put words together but need someone on CSS side
  <bkardell> would be curious to work with this volunteer some
  AmeliaBR: I can help

  ACTION: Amelia and tink to draft a proposal
  <trackbot> Created ACTION-883
  <IanPouncey> I can also help.
  astearns: and bkardell

  <AmeliaBR> Rossen, this is an example of what jcraig was talking
             about. I'm not seeing the `aria-hidden="false"` heading
             in the EdgeHTML accessibility tree:
             https://s.codepen.io/AmeliaBR/debug/43c7bca3b5d0b15f5f167a29c5524e73

Remove section of CSS Transforms 1
----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3870

  krit: To summarize issue here, we have a spec where animations are
        applied to transforms in the transforms spec with combination
        of SMIL
  krit: but I think this entire section should be removed
  krit: Section introduces transform to the animate and set elements,
        both SMIL elements that refer to svg animations
  krit: in addition to what is in SVG already
  krit: But there is no implementations and no interest to implement
  krit: so request to either defer or remove entirely
  krit: If section gets removed, then there's nothing about motion in
        the spec anymore

  AmeliaBR: Issue is just asking you to add an accessibility section?
  krit: Issue was about adding section about accessibility
  krit: but we removed the section reference to motion, so no need for
        adding an accessibility section
  AmeliaBR: One paragraph of animating transforms can be bad ?
  fantasai: Anything can be animated, width, margins, etc. do we add
            warnings to every layout feature of CSS?
  fantasai: I think better to keep in the animation section

  AmeliaBR: So requesting to close this issue as wontfix and follow up
            with getting it addressed in CSS Animations
  krit: Yes, but request would be to defer the entire feature
  krit: if we want to do that, would suggest to try with SVGWG or
        SVGCG first
  AmeliaBR: So other feature request is adding way to pause CSS
            Animations, which we don't currently have
  krit: Right
  AmeliaBR: Don't see why this should be deferred to SVG, CSS
            Animations has ...
  <tantek> I'm wondering if the request for the ability to "pause
           animation" also includes the ability to slow down the
           animation

  fantasai: Do we need to discuss all this with A11y?
  krit: Need to close issue no change because moving the section
  IanPouncey: Comment about documenting a11y concerns
  IanPouncey: while I don't have a particular problem in this case
  IanPouncey: just want to say the way people use these documents is
              to find example they need and copy it directly
  IanPouncey: Not going to look at different document
  IanPouncey: In some cases we might want to have notes in multiple
              locations therefore
  krit: Would maybe put in boilerplate to add to every single module
  fantasai: If you put it in the boilerplate, it'll be at the top of
            the spec, and someone linking into the middle of the spec
            won't see it. maybe in the animation type definition?
  fantasai: which is linked from propdef table
  IanPouncey: Happy to draft that note
  AmeliaBR: I like fantasai's point, we do have a link from every CSS
            property definition "Animation Type", can put the note
            there
  AmeliaBR: Each spec item in the spec would be connected to the
            warning

  AmeliaBR: Proposal is wontfix on request to add a11y consideration
            section to css-transforms
  AmeliaBR: for the remainder of the issue, request for pausing/
            stopping
  AmeliaBR: that will be opened as new issue on Animations or
            Transitions
  krit: Can only wontfix if remove the animation section
  krit: so request is to remove animation section
  krit: since feature that is added on top of SMIL and no interest
        form implementers and from community
  astearns: So proposed to remove the section and wontfix the issue
  AmeliaBR: Can be moved to SVG Animations Level 2 which may or may
            not ever go anywhere
  AmeliaBR: but that's where the text is lived
  astearns: Open a separate issue on that
  astearns: for this particular issue, remove section and wontfix

  RESOLVED: Remove section on animation and wontfix issue about
            paragraph about accessibility because no longer relevant

  astearns: Out of time

<br type=lunch>
Received on Tuesday, 3 December 2019 23:14:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:14 UTC