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

[CSSWG] Minutes TPAC F2F 2017-11-07 Part II: Spatial Navigation, nav-*/tabindex, a11y Joint Meeting [css-ui]

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
Message-ID: <e49a0d7c-95b6-a9bd-829a-7e0538906469@inkedblade.net>

   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.


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

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
   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
   jihye: *shows a testcase*
   jihye: It isn't perfect but we need to improve the mechanisms in
   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
   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

   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
   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
   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
   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
   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
   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
   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
   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.


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
   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.


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
   <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
   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


   ??: 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
   <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
   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
   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
   <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

   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
   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 +
   <jcraig> +1 to discussing specific sequential navigation ordering
   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:

   <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

   <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
   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,
   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)

   jensimmons: Alice, you mentioned keeping visual and DOM order
   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,
   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
   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
   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
   janina: Surprised us a bit by agreeing with us before we got very
   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:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:04 UTC