- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Dec 2019 18:13:40 -0500
- 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:36 UTC