- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 23 Dec 2017 10:00:34 -0500
- To: "www-style@w3.org" <www-style@w3.org>, public-css-a11y@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.
=========================================
CSS UI 4 / Spatial Navigation
-----------------------------
- LG's proposal to address spatial navigation heuristics solicited
interest in improving spatial navigation in the Web Platform;
conversation will continue in WICG.
- There was debate on if issue #1910 (Make directional navigation
more composable: https://github.com/w3c/csswg-drafts/issues/1910 )
is in scope for CSS UI or if it belongs in another forum.
- No resolution or conclusion was reached before the group had to
take a break.
Accessibility Joint Meeting
---------------------------
- The joint meeting started with an overview of the task force
status - There are now several sections on github to cover high
level problems for the task force to cover.
- An a11y tag was created for CSS github issues that came out of
the task force.
- The group spoke about broad issues around navigation.
- The task force was told about the spatial navigation
issues raised earlier in the day being moved into WICG.
tantek indicated that the task force members are welcome to
join the WICG meeting on Thursday if they're available.
- Ability to navigate in a spatial order was raised as very
important both for visually impaired users who may
experience a disconnect with the visual arrangement and
for users that are completely blind since they have a
strong sense of spatial order that is also being broken;
Florian raised the question of whether some kind of
spatial sequental (2D flattened to 1D) order was necessary
or if a 2D spatial navigation mode would be better.
- jensimmons and Florian pointed out that visual order is not
necessarily left-right/top-bottom since visual hierarchy
is involved; and designs going forward are likely to rely
more on other aspects visual hierarchy than box coordinates
to communicate page organization.
- Previous attempts at customizing sequential navigation were
problematic; lack of scoping/grouping was one major missing
piece. Solutions would likely involve CSS/HTML/DOM/Web Components
(hence incubation in WICG).
- There is a need for concrete use cases of where navigation is
currently broken to support the process of developing solutions.
- There is a less-discussed use case for personalization of
ordering for different types of users. The group needs to
solve for more then just the fully blind or visually
impaired: this is also a problem for people with cognitive
differences and the aging population.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda
CSS UI 4
========
Scribe: gregwhitworth
Spatial Navigation
------------------
github: https://github.com/lgeweb/spatial-navigation/blob/master/explainer.md
[going through https://github.com/lgeweb/spatial-navigation ]
jihye: Spatial navigation is the ability to focus elements based on
their position on the screen
jihye: the focus key can be changed with tab or shift tab key
jihye: two way remote control and with four way keys and a11y it is
becoming more and more important for input mechanism
jihye: it is interesting for a11y for explaining the layout of the
page
jihye: to support this, we need to consider the following three steps
jihye: *reads from explainer*
jihye: The heuristic will be built for navigation, tab and arrow
keys in Opera/Vivaldi allow for spatial navigation.
jihye: Blink it moves the scroll bar but you can enable it via a
flag.
jihye: *shows a testcase*
jihye: It isn't perfect but we need to improve the mechanisms in
blink.
jihye: [shows that when you press arrow keys it goes to the
focusable elements]
jihye: [shows the heuristic on scrollable regions that allow it
scroll until a focusable element is in view that element is
then given focus]
<tantek> I wrote code to do this (user-friendly spatial navigation)
automatically in Tasman for WebTV/MSTV back in the day but
cannot remember exactly how I solved all these problems.
<astearns> https://drafts.csswg.org/css-ui-4/#nav-dir
jihye: In CSS UI there are left, right, up, down properties.
jihye: It is quite inconvenient because it needs to be defined on
each element.
jihye: I want to solve this problem.
jihye: *shows page with proposed API page from explainer*
<astearns> nav-rule: auto | projection | direction | nearest
<astearns> (describes nav-loop)
jihye: There is a rule that can customize spacial navigation.
jihye: When the page is too long and a lot of scroll, when the focus
reaches the bottom of the page, the focus can go to the next
thing and when you want to go up you need to press the up key
so many times, but loop can go directly back up by going to
first focusable element in the tree.
jihye: Does the WG have any feedback?
fantasai: The first question I have is, some of these things seem
like as a user preference rather than an author preference.
florian: Which ones?
fantasai: Like the loop.
florian: There is a tv program, being able to move the left to the
right is dependent on layout.
florian: The person that knows how this is laid out is the author
florian: and that's why it should be on the author, but that's the
general state of CSS.
myles: So I think in general, I think it's a good area of
investigation.
myles: There are many devices out there that use spatial navigation.
myles: The heuristic for arrow keys there isn't a lot of interop,
that would be valuable, but I also think there is a place for
the web author to override the default.
myles: I think there is definitely a case for author tweaks to the
heuristics.
florian: I think there are three: 1. Leave it up by the UA 2.)
Picking the bit that you want to override
florian: I do think we'll need some specifically selectable method,
and I don't think today we can define this - we need to
take some type of extensible web approach here:
florian: send an event when the user tries spatial navigation
florian: then a little bit down the road we can enable it based on
usage.
florian: Having worked a little bit, there all sorts of corner cases
florian: transforms, opacity, etcs.
florian: I don't think we should dictate the heuristics right now
will be very hard, not the whole problem.
fantasai: What would be the advantage of events over using nav-*?
fantasai: You're saying we should have an event handler and then do
that live, we allow JS to set the nav-* properties
fantasai: a page that has too many JS.
fremy: (replying to fantasai; pointed out that there is a perf cost
to giving an id to all focusable elements and changing their
style in a unique way that would prevent style reuse)
tantek: I have some experience working on this, there are a couple
things worth looking at.
tantek: The first of - what are the real world layouts that authors
have used
tantek: where automatic algos haven't done a great job.
tantek: If any of you were at jensimmons talk laid out in a circle
they expect the focus to go in the circle.
<tantek> https://lists.w3.org/Archives/Public/www-style/2013May/0076.html
tantek: We've tried to solve this before, it's very hard and this is
beyond CSS and brain storming here isn't going to be a good
use of time.
tantek: If you want to pursue this, make it a platform effort.
tantek: I'd hate to see you spend a lot of time on that and hit a
lot of the same issues we've hit before.
fantasai: The key thing to point out from the email is being able to
group elements rather than just one thing after another.
astearns: Any other points you'd like to make jihye?
jihye: I'm looking for general interest?
<tantek> I think spatial navigation would be better pursued in a new
WICG draft
astearns: I think this should start in the WICG and get wider
interactions
florian: The thing is, what do we mean by "THIS"
florian: This an entire area of features.
iank: That's what WICG is for, find the problem and then start
identifying and beginning to solve the problem.
astearns: Taking this to WICG, doesn't preclude us from making
changes to things that are already in CSSUI.
tantek: We'll definitely help out here in what makes sense being in
CSSWG.
florian: As long WICG doesn't preclude us, I'm ok.
jihye: I'm on Discourse.
astearns: we should take it from Discourse and make an official WICG
repo
jcraig: We should solve this in WICG but with everyone, CSS is part
of it but we should include solutions to tabindex, etc.
<bkardell> +1 to jcraig's comment
<tantek> +1 to jcraig's comments
jcraig: This will fail on its own in the weeds.
Make directional navigation more composable
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1910
florian: One of the weird things that we have with arrow keys, it
lets you define where you should focus to.
florian: What happens if the element where you want to go to isn't
focusable?
florian: What is currently defined is that if the user wants to go
there we should make it focusable
florian: These days many/most are built are out of components.
florian: This may allow the browser to go the "right" and then seek
for the first focusable element.
florian: If you're the author you can point to what's there, if your
using a component and you don't know what's there maybe a
heuristic is better.
tantek: As an author you may want to use a seamless iframe but you
don't know what's on the other side. I don't think we can
determine the best behavior.
tantek: Since you mentioned components, I think we shouldn't be
solving this in isolation.
florian: I'm not disagreeing with what you state, I'm not sure how
that answers my question.
tantek: I'm saying this discussion doesn't belong in CSSWG.
smfr: So are you saying these props don't belong in CSSUI
smfr: To me, it sounds like spacial navigation would be in its own
spec rather than here in its own naïve form.
florian: Do you think there is a potential case where the focusable
behavior is what you would want?
tantek: Very unlikely.
florian: I think searching inside of that makes sense and is
uncontroversial.
tantek: You're asking about something in the weeds and I'm not sure
it helps/hurts and I think we should move this to a
different arena.
astearns: Is anyone lining up to implement this improvement, then I
think there would be a case to make a change to the spec.
astearns: If this is just an academic change, what's the point?
florian: The fact that, it works poorly when you have blackbox
component which was mentioned by Blink.
tantek: I don't think it's experimental.
<tantek> issue filed: https://github.com/w3c/csswg-drafts/issues/1948
<tantek> " [css-ui-4] Spatial Navigation needs a new home in WICG
#1948 "
<robdodson> (sorry for speaking out of turn) but the notion of
creating focus "groups" seems to already exist today
with Shadow DOM. jsbin.com/lidaguf/edit?html,output
astearns: *reads rob's comment*
robdodson: The notion of focus groups kind of exists already, that
will allow once focus is within that shadow root boundary.
robdodson: The notion of the grouping kind of exists if you're
willing to use shadow dom.
<tomalec> AFAIK, Shadow DOM also propagates, kind of scoped focus,
to elements distributed via `<slot>`
florian: What I was thinking of trying to specify if you focus that
non-focusable element - if there is tabindex, etc use that.
florian: Since we don't seem to have consensus can I suggest a
lighter one to make a change to what we agree is stupid.
bradk: What do we all agree is stupid?
bradk: Currently you only seem to say that you should look for
tabindex.
florian: Or is a button, etc.
florian: It seems very weird to me that something is focusable will
take you to something that isn't focusable but with a tab
key you can't.
florian: That's weird.
astearns: Since we're not closing, let's table the issue for now.
<br>
Accessibility Joint Meeting
===========================
Scribe: TabAtkins
janina: We've been listing some issues with CSS for several years,
and tried several ways to get traction.
janina: Had some wonderful conversation; some issues are on our end.
janina: Formed a TF a year ago, had some trouble staffing it on our
end.
janina: Think we've got it staffed now.
janina: Ian Pouncey. Ted Drake is still involved.
janina: Want to talk process, introduce the TF between CSS and ARIA
and APA.
janina: Illustrating some persistent issues that keep showing up -
we've picked one to kick around a little bit.
[intros]
Task Force Progress/Overview
----------------------------
IanPouncey: Have a bit of an agenda.
IanPouncey: First item is a history lesson on the TF.
IanPouncey: Discussed at last year's TPAC and activated in Jan 2017.
IanPouncey: Took a bit to get going.
IanPouncey: Back in August my employer gave me explicit time.
IanPouncey: Have reviewed 4-5 modules and commented on one - MQ4
IanPouncey: Lots of work, have limited participants. Here today to
ask for your help.
IanPouncey: Anyone interested in participation in the a11y TF,
please contact us - I'll put some email addresses in the
IRC channel.
<IanPouncey> public-css-a11y@w3.org
<IanPouncey> w3c@ipouncey.co.uk
<MichaelC> -> https://www.w3.org/WAI/APA/task-forces/css-a11y/ CSS
A11Y TF
IanPouncey: First, what's the best way to interact with the CSSWG.
IanPouncey: We've raised one issue so far.
<IanPouncey> https://github.com/w3c/csswg-drafts/issues/1925
<MichaelC> -> https://github.com/w3c/css-a11y/ CSS TF GitHub repo
IanPouncey: So far all I've done is tagging it appropriately.
<smfr> maybe css-a11y could be a github label
florian: I've seen this review - one reason to not dive in yet is
that this is one review, but lots of issues.
florian: Would be much more digestible if each issue was a separate
GH issue.
florian: Some are linked so it's not always obvious, but one giant
issue makes it hard to look at.
fantasai: We do have tags we can use - you can tag them all together
and easily tell what to pay attention to.
fantasai: We have a tag specifically for *requesting* a11y feedback,
but we can add another tag for feedback specifically from
y'all.
<MichaelC> if you want to mint a tag for accessibility, I suggest it
be just a11y
[someone says "a11y" label]
fantasai: Sure.
IanPouncey: Dunno if we want to differentiate between review from
individuals and from the TF?
Rossen: Not really different. One of the motivations behind the TF
is that there's a group dealing with CSS a11y focus offline,
so it doesn't take a ton of time otherwise.
<MichaelC> a11y is the label likely to be magiced in the future like
the i18n label; others could be used for non-magic
labeling
Rossen: Once those issues are identified and we've convinced
ourselves we need to solve them, we can move them to the
csswg modules and start tracking the work there.
Rossen: But echoing fantasai, issues are issues, no reason to deal
with yours specially.
Rossen: Let's just use the "a11y" label, then.
Rossen: Less process in the way, the better.
<Chris> ally label created
<TabAtkins> hopefully a11y, not ally?
<Chris> yes a11y
IanPouncey: There's a label for specs that need review?
<jcraig> “Needs a11y feedback” label https://github.com/w3c/csswg-drafts/labels/Needs%20a11y%20feedback
<jcraig> Master list of CSS GH labels: https://github.com/w3c/csswg-drafts/labels
<IanPouncey> https://github.com/w3c/css-a11y/projects/4
Navigation
----------
??: We set this project up 6 months ago, but have been adding as we
went along.
IanPouncey: Currently there are 13 specs in this project, question
is how do we add to it and communicate what needs
review, and how to prioritize.
IanPouncey: So one example spec review as an example.
IanPouncey: Topic is navigation, in combination with the layout
specs.
<IanPouncey> https://github.com/w3c/css-a11y/projects/1
IanPouncey: We have a project in the a11ytf specifically for layout,
but not much there at the moment.
IanPouncey: Round Display, Position, and Fragmentation
IanPouncey: Need to put Grid in there.
IanPouncey: Grid currently has a single piece of advice-
<IanPouncey> https://www.w3.org/TR/css-grid-1/#placement-a11y
IanPouncey: Advice is basically just "don't mess it up", and to pay
attention to content order.
IanPouncey: Question we have - is this sufficient? We know it's not
a new problem.
<fantasai> See also https://www.w3.org/TR/css-grid-1/#order-accessibility
IanPouncey: We still see a lot of issues from devs tho
florian: I had a discussion yesterday - "source order nav is king"
has been longstanding advice, and we've pushed back against
shortcuts taken by well-intended people who don't want to
bother about that, and we've thought...
florian: But maybe there are places you do need the different
behavior.
florian: Different cases for different a11y needs - probably
non-sighted users can live in a world where DOM order is
king - tabbing thru DOM order seems to make sense
<aboxhall> also note that not all assistive technology users are
non-sighted
florian: But for sighted keyboard users this is less true - a
stronger disconnect between what they see and where the tab
key takes them.
florian: We're thinking about addressing this through spatial nav
rather than re-ordered sequential nav
florian: "take me to the next thing" might take to an unexpected
place, but "take me to the next thing to the left/up/etc"
might be more useful. Was just discussing that.
florian: Does this high-level description make sense? Do we need
re-ordered sequential nav once we have spatial nav? What
other things do we need?
IanPouncey: This is the sort of thing we want to talk about!
jihye: I just gave a presentation on the spatial nav proposal.
IanPouncey: A question is, is this something that needs to be
considered? Should DOM be the only source of truth? Can
this be fixed with better docs?
IanPouncey: We know this isn't working, devs aren't getting the
message.
<tink> https://1drv.ms/v/s!AvBfF-T7CmB2het1xoPdYm0kee63Tghttps://1drv.ms/v/s!AvBfF-T7CmB2het1xoPdYm0kee63Tg
<tink> Please ignore the sign-in on the URL above and the video
should be available.
Rossen: Our last half-hour before this is that we recognize the
problems, some might need to be fixed on the css layer, and
it's a much bigger-scope problem than just the CSSWG.
Rossen: Our preference was to move this to a WICG group and have a
broader exposure and request for feedback and input.
Rossen: Particularly for people on html and dom side
Rossen: And if anything falls out that is specific to css, we'll
bring that back as appropriate.
Rossen: This is definitely something to be solved, just want to make
sure it's the right set of people, not necessarily just CSS.
florian: To expand, it's obvious that spatial nav is related to
layout, but not *only* - it's also interacting with JS,
with web components, etc.
florian: Things this group doesn't master. We should be involved,
but not just us.
florian: But still question of if there's something left to solve in
sequential nav once we've solved spatial nav.
tink: Wanted to emphasize that this isn't a new problem, florian
suggested this already.
tink: Become more of a priority now because CSS modules are fixing
long-term problems with layout, making re-ordering so much
easier, so it's becoming a larger problem now.
rachelandrew: In the past I've said I'm happy to contribute examples
or feedback form community
rachelandrew: When I teach Grid, people say "oh, makes it so easy to
have a different layout for desktop vs mobile"
rachelandrew: I teach not to have different orderings, and people
say "oh, but surely that's what this is for?"
rachelandrew: So there's a real use-case for the re-ordering.
rachelandrew: So happy to contribute my experience teaching devs
here.
jensimmons: I want to assure people that we've had extensive convos
about this.
jensimmons: I've been talking to Rachel and a11y experts outside the
WG for months, etc.
jensimmons: Briefly, I'm hesitant to get away from DOM order. Leaves
authors who want to do the right thing without an idea
of what to do.
jensimmons: Always need more education, always.
jensimmons: I know that still leaves a gap, a lot of authors just
don't understand what they're doing.
jensimmons: Was talking to Derek Featherstone, does a11y
retro-fitting for sites, and he felt like the only thing
that would work is a user pref.
jensimmons: DOM order staying the best preference, but a switch to
visual order for people who'd prefer that.
jensimmons: So yeah, need to have the right people in the room for
this.
IanPouncey: Yeah, bringing this to the WG because we know it's
something of interest.
Chris: An example where document order is not what you want.
Chris: An SVG which is a map, a thousand villages, rivers, etc.
Chris: Probably don't want it to start at top and work down. Want to
start from a point and move spatially.
<tink> +1 to Chris
astearns: There were two topics on sequential nav on our agenda,
thought they might be good in this meeting.
<astearns> Controlling sequential navigation issues:
https://github.com/w3c/csswg-drafts/issues/1748 +
https://github.com/w3c/csswg-drafts/issues/1764
<jcraig> +1 to discussing specific sequential navigation ordering
issues
IanPouncey: If there's gonna be a WICG group, make sure the tf is
involved - we can help facilitate.
florian: For topics in WICG, typically people involve themselves;
I'm happy to invite the right people
florian: Who are they? A mail to the taskforce is the way to go?
IanPouncey: Perhaps the right people are the ones from the CSSWG
that will volunteer...
florian: Where should I send a mail to?
IanPouncey: Put it earlier in the chat, there's a public email for
the tf
<IanPouncey> public-css-a11y@w3.org
janina: Ian coordinates with APA all the time on this, so we have
ways to find people with the right expertise.
MichaelC: Part of the purpose of the APA was to incubate solutions -
are there benefits to working with the WICG that aren't
obtained by our tf? Want to know we're working in the
right incubator.
tantek: The experience we've had is that trying to solve this just
in css won't work, as pointed out for previous reasons.
tantek: In WICG, the point is to consider styling, markup, and/or
script-related aspects of navigation. They all inter-relate,
plus tabindex, etc. Solving only in CSS, likely to repeat
years of frustration.
tantek: So earlier, just from the WG's perspective, made sense to
take this to WICG.
tantek: And point out - WICG is holding meetings all Thursday. If we
have a quick repo, we can reconvene during one of those
timeslots on Thursday.
<Chris> see also https://discourse.WICG.io/t/proposal-spatial-navigation-for-the-web/2402
florian: We've had a few proposals to try and solve the
reordered-sequential nav.
florian: Quick overview:
florian: As a complement to the spatial nav up/down/left/right,
there's a proposal for nav-next/prev, directing where the
Tab should take you.
IanPouncey: Android has a similar thing.
florian: There's been suggestion that you don't need both, you could
infer -back from -next
tantek and tab: No you can't, you can have multiple things pointing
to the same.
<tantek> no, nav-index was removed due to being an incomplete
solution and having accessibility issues
florian: Another is to move tab-index to CSS.
florian: And/or combined with something letting you scope it to
subtrees of the DOM, letting you re-order parts without
interfering with the rest.
florian: Hard to talk about what to do for these and how to tweak
them, without knowing what needs to be solved, and what's
left to solve after spatial navigation happens.
florian: Not saying there will be nothing left after spatial nav,
just not sure what it will be.
IanPouncey: Lacking testcases?
florian: Use-cases. Saying here's a page, fix spatial nav, clearly
something is still broken.
florian: So finding cases where DOM order is right, visual order is
inconsistent, and it's a problem... list of these sorts of
cases are what's needed.
florian: I don't have a good understanding of that; I don't think
anyone does yet.
janina: Same problem in APA, we need to frame this up better.
<jcraig> Adding scoping issue from list mail a few years back:
https://github.com/w3c/csswg-drafts/issues/1949
<aboxhall> I think it should be noted that ideally visual order, AT
traversal order and focus traversal order should be in
sync at all times
<aboxhall> Fixing one of those in isolation risks getting them out
of sync
<tantek> aboxhall agreed and I think that's worth q+ing to say
outloud
<tantek> jcraig do you have a link to all the problems with TABINDEX?
<jcraig> tantek, I don’t know that there is a definitive list of
*all* the problems with tabindex
<tantek> jcraig, I vaguely remember you pointing me to a "problems
with tabindex and proposals for fixing it" document years
ago and I can't find it
aboxhall: Ideally visual order, AT order, and focus order need to be
as close as possible. Anything touching one of those risks
them getting out of sync.
<mck> Visual positioning is important to blind users.
florian: Why is that a problem?
aboxhall: Not all AT users are non-sighted, so it's confusing to get
those out of sync.
aboxhall: If tab and visual order are out of sync, tab order flies
around the page.
florian: We haven't had spatial nav on mainstream browsers so far.
If we did, I suspect sighted keyboard users, when they want
to go right, will want to go right, rather than going
"next" and hoping it's to the right.
<tantek> left/right does not translate to next/prev universally
across cultures!
florian: I'm also not convinced that "visual order" is actually a
thing - points are in 2d, they're not ordered, contrast and
motion and such also matter...
aboxhall: I think there's a difference between "DOM is linear" and
"visual order doesn't matter". You can have regions that
have a very logical visual order, like a tablist.
* tantek is really glad jcraig and aboxhall are here for this
florian: Right, locally there is, but in those cases you listed, DOM
order should already match.
florian: Not saying they don't exist, but as long as we merely
*assert* they exist, we won't have an idea what they
actually are.
florian: Often in same order, but in the cases they're not, to me,
it seems that spatial nav is better for sighted users.
florian: Overlapping problems and solutions, and once we consider
future ones we've committed to, what's still uncovered?
aboxhall: I think those have answers, but this meeting isn't the
place for them.
florian: I think I have answers, but it's based on personal
preference right now.
florian: I just don't think we can have a productive discussion
before listing use-cases
aboxhall: I think we agree.
janina: We're dancing on the edge of some concerns - personalization
will come up, different users will want different things.
Making that possible is another convo we want to have.
<fantasai> +1 to janina
<aboxhall> +1 janina
mck: As a blind user who I think can rep blind users well - I want
to say as forcefully as I can, VISUAL ORDER MATTERS TO BLIND
USERS.
mck: Happy to talk extensively for more detailed reasoning.
mck: One important reason is the existence of touch screens.
jcraig: Visual layout affects the spatial orientation, and
completely blind users are very aware of spatial orientation.
jcraig: And most visually impaired people aren't completely blind -
a new study came out recently said 230mil people in the
world are impaired, only about 50mil would be called
completely blind.
jcraig: Most screen-reader users probably aren't completely blind,
too.
jcraig: We get bugs all the time were the screen-reader doesn't
align with the visual order.
jcraig: I've heard assumptions in the past that people are either
sighted and not using AT, or totally blind, and that's not
true. It's a big multi-pole spectrum.
<Chris> +1 to jcraig about sliding scale
<jcraig> Stats and resource site for blindness and vision
impairments around the world… (disclaimer: site itself
unfortunately has a number of accessibility problems)
http://atlas.iapb.org
jensimmons: Alice, you mentioned keeping visual and DOM order
together.
jensimmons: That's absolutely what we're teaching right now.
<tantek> +1 jensimmons
<aboxhall> I'm actually less concerned about DOM order - focus
traversal order and AT traversal order are my concerns
<aboxhall> if they diverge from DOM order but stay in sync that's
probably? ok?
jensimmons: Florian, I think you were onto something. Saying "what
is visual order" "what is spatial order"; layout design
will change drastically over the next few years, if my
last few years of life meant anything, and "what is the
visual order" doesn't have a clear answer. Very
subjective, involves visual hierarchy.
jensimmons: So that's probably part of the disconnect - loose notion
of a clear order. When you hit 2d or 3d, a more visual
amorphous order. Maybe more about thinking of a set of
navigation tools that work in a more visual space.
<florian> +1000 to jensimmons
jensimmons: Just, don't think webpages will continue to look like
they do - header/nav/main/etc. I'm encouraging people to
play with this, but telling people to build an
accessible dom first.
fantasai: How many people have seen Jen's presentations on Grid?
fantasai: If you haven't, I recommend you find a video. I can't
emphasize enough how the difference is going to be, and
visual order will not be left->right, top->bottom. Will be
much different from just scanning coords.
<jcraig> link to jensimmons presos?
<Chris> jcraig see http://jensimmons.com/post/feb-27-2017/learn-css-grid
and http://labs.jensimmons.com/
<jensimmons> this video is a good one: http://jensimmons.com/presentation/revolutionize-your-page-real-art-direction-web
leaverou: A common use-case I haven't heard yet:
leaverou: When you're writing a library augmenting elements on a
page you don't own, when you need to append and position
relative to something else, often easier to append to body
and just visually position them, rather than appending
near the element and deal with stacking context, overflow,
etc.
leaverou: This applies to libraries that do tooltips, editing...
[Missing some of Lisa's call]
lisa: One of the things that might help is predictable positioning.
lisa: If people expect it to be a distance from the corner of the
screen, they know where to find things, where the search can
stop.
lisa: A MQ I don't know exist, dunno if interested in use-cases for
this, but I think it might fit in somehow...
[still missing details]
<jcraig> lisa please type your comments… some was lost on the phone
call reception
<lisa> wondering if we should build use case for personalization for
people with cognitive disabilities, either via media queries,
or for predictable positioning here.
IanPouncey: There was a discussion last year about the possibility
of MQ helping personalization.
IanPouncey: Dunno how that would work with layout, but it should be
mentioned.
IanPouncey: A preference for spatial nav vs DOM order communicated,
maybe thru MQ.
george: IPDF has merged with the W3C, so publishing is now under
w3c, including epub
george: DOM order and publishing's "correct reading order" are
closely linked
george: Need to be able to maintain that not even in a single
webpage, but across a collection of items.
george: In visual vs DOM order, there are things we need to
preserve. If a skull-crossbones is next to a note, need to
make sure the warning is read before the note, so people
don't hurt themselves.
george: So this is important discussion in the epub wg.
janina: Thank you for the time.
janina: We should be careful not to limit where we think the
problems are.
janina: Range of people affected is far larger than just fully
blind, or even just visual disabilities.
janina: People with cognitive or learning disabilities are big part,
aging population is big part.
janina: Analogy - if you move to new city, everything you're used to
is there, but in a new location. Re-orientating is hard,
people can get dropped.
janina: So I think we need to look for the commonalities and ways to
let people make things work for them.
janina: Like "what does next and prev mean" and make it work
hierarchically.
janina: Surprised us a bit by agreeing with us before we got very
far.
janina: Looking forward to looking at this as we move forward.
Rossen: Those who are interested, plz join the css-a11y list.
Received on Saturday, 23 December 2017 15:01:17 UTC