W3C home > Mailing lists > Public > www-style@w3.org > June 2015

[CSSWG] Minutes New York F2F 2015-05-20 Part IV: Flexbox Order Accessibility

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 20 Jun 2015 08:42:46 -0400
Message-ID: <CADhPm3vBJ73E3PRuLscWoZM3ziq3XJ87DSB4Yn=Bd2dwyKHYeA@mail.gmail.com>
To: www-style@w3.org
Flexbox Order Accessibility

  - Bo brought the concerns about Flexbox's ability to reorder
      visual layout running into accessibility concerns when that
      visual sequence change is important to the reader's
  - As the conversation progressed, tantek pointed out that this is
      a problem experienced by many specs, not just Flexbox, and the
      group turned to trying to see if there's a solution that could
      fix it for all layout specs instead of focusing just on
  - Bo will bring examples of broken pages to the group to see more
      of the exact problem and Tab will contact the WebApps group to
      explore a reordering API.


  Scribe: fantasai

Flexbox Order Accessibility

  Bo: There's an a11y concern with Flexbox, wrt WCAG 1.2 and
      meaningful sequence
  <ChrisL> http://www.w3.org/TR/WCAG20/#content-structure-separation
  <ChrisL> Guideline 1.3 Adaptable: Create content that can be
           presented in different ways (for example simpler layout)
           without losing information or structure.
  <ChrisL> 1.3.2 Meaningful Sequence: When the sequence in which
           content is presented affects its meaning, a correct
           reading sequence can be programmaticly determined.
           (Level A)
  Bo: I've learned a bit since then.
  Bo: Focus is more specific.
  Bo: When we were talking about holy grail layout with Flexbox.
  Bo: Being able to reorder things visually without changing logical
  Bo: All fine, until you change a visual sequence that's meaningful
      to the reader,
  Bo: e.g. you change header and nav of a page,
  Bo: and you move those around.
  Bo: The sequence doesn't matter.
  Bo: It does cause problems with person using keyboard + magnifier.
  Bo: I think we're overlooking that.
  Bo: Key issue is that within one of these sections,
  Bo: if you have nested Flexbox in there, and sequence of items in
      there, logical order is important.
  Bo: And you have rearranged them with Flexbox 'order'.

  Bo: As I understand it, reverse is still reading in logical order.
  Bo: For 'order', Firefox uses visual order right now.
  Bo: We like that.
  Bo: The proposal is really about, discussion about, the option for
      an author to say that "I'm changing the order of a meaningful
      sequence, and ..."
  Bo: If I'm using Flexbox to reorder something visually, and the
      sequence in the DOM no longer makes sense (e.g. to screen
  Bo: then there should be an option to say that this is a
      meaningful sequence, let's go through the visual order.

  ChrisL: I heard you say you wanted two things: read through DOM
          sequence and read through visual sequence.
  ChrisL: And the trigger for that is when the DOM sequence no
          longer makes sense,
  ChrisL: when the visual order has changed, in a way that changes
          the meaning.
  Bo: The example I use when teaching designers is "how to use a
      defibrillator" in 4 steps.
  ChrisL: But what you said is that "order in the DOM no longer
          makes sense".
  ChrisL: I can't imagine anyone making a "How to use a
          defibrillator" with DOM in the incorrect order.
  ChrisL: Why wouldn't you just put it in the right order in the DOM?
  plinss: Maybe ad-injection?
  ChrisL: Yeah, there's content you need and content you
          unfortunately get.

  leaverou: You have a list of topics in a forum.
  leaverou: Some have class="sticky" or "pinned", cause you want
            them pinned to the top.
  leaverou: Posts are in the chronological order.
  leaverou: Use order: 1 to move to the top.
  <tantek> e.g. pinned posts, http://indiewebcamp.com/pinned

  Bo: ... more examples
  Bo: What we're forcing authors to do, if we say in the spec, you
      have to follow meaningful sequence,
  Bo: and you have an entire page with Flexbox in the middle of
      another section, and need to rearrange that,
  Bo: you're forced to use tabindex through your entire page.
  Bo: No easy solution to make the page accessible.
  Bo: Spec says you need to use tabindex.
  fantasai: What? No...
  ChrisL: What it's saying is, for an a11y tool which is not reading
          the style sheet but which wants to get the same reading
          order that would get using a style sheet.
  ChrisL: Suggestion is to redundantly encode using taborder.
  fantasai: That sounds terrible.
  tantek: It's a classic example of DRY violation.
  <tantek> (DRY) http://indiewebcamp.com/DRY
  <ChrisL> yeah I was arguing that it was terrible (in case my
           comments could be read the other way)
  fantasai: The spec says if the sequence change is meaningful, the
            DOM should be reordered.
  <dbaron> http://dev.w3.org/csswg/css-flexbox-1/#order-accessibility

  Bo: Authors are doing this for performance reasons, in order to
      not update the DOM.
  Florian: I think that's the critical point.
  Florian: There are two cases:
  Florian: a) Authors are writing incorrect order for various
           reasons, and then correcting with Flexbox.
  Florian: We should not fix Flexbox, shouldn't try to make a right
           out of a double-wrong, when Flexbox can be used correctly.
  Florian: b) There are two valid meaningful orders, one which is in
           the DOM, and which is correct (if was incorrect, reorder
           DOM). But *another* meaningful order is expressed in
  Florian: and want to be able to follow that ordering.
  fantasai: Closest case for b is I think leaverou's example

  tantek: This presentation order vs. dom order issue isn't new to
  tantek: Every layout mechanism allows you to do this.
  tantek: What's the general approach, rather than picking out
  [people list various layout modes that have this problem]
  tantek: Happening for decades.
  fantasai: They've been complaining about this problem for decades.
  tantek: How do we solve this *class* of problems?
  tantek: I could recreate this problem in many different ways.
  fantasai: Tantek is saying, we should address this problem as a
  fantasai: 'order' is just the most staightforward expression of
            this problem. Makes it seem simple to solve because it's
            an explicit control, but can get the same problem as
            implict result of layout calculations.
  tantek: There's more examples of this problem with float than
          Flexbox, given its legacy.
  tantek: If you're trying to solve presentation order vs DOM
          reading order, those examples are worth looking at more.
  Bo: Those are also inaccessible. It's against the WCAG.
  ChrisL: You're both saying the same thing.
  Rossen: Why only fix for Flexbox?
  Bo: Possible to do that, would be great.

  fantasai: There's two classes of authors here.
  fantasai: First class follows best practices, keeps DOM in logical
            order, might use CSS to reorder visually in cases where
            visual order and reading order should differ.
  fantasai: Second class is authors who use whatever tool in front
            of them, don't think about a11y or DOM order.
  fantasai: In the first case, we *want* to give them the ability
            reorder only at the visual layer. Otherwise they reorder
            everything to get correct visual order correct, and
            logical order ends up wrong.
  fantasai: In the second case, you want to follow the visual order,
            because that's most likely to be correct; DOM could be
            completely random.
  fantasai: For the second group of authors, we need to have the
            most easily-used tool to be the one that reorders also
            the speech order.
  fantasai: For the first group of authors, we need to make it
            possible to do visual-layer reordering, but to keep away
            from first group, need to make it a very specific thing
            they have to choose.
  gregwhitworth: [something about a11y tools looking at DOM tree vs
                 visual tree]
  Bert: Early a11y tools looked at visual output rather than DOM.
        It was not very useful.

  fantasai: I think this might be a navigation problem for a11y
            tools for people who use both sight and speech.
  fantasai: Might want ability to navigate visually as well as
  fantasai: but that's for a well-designed page.
  fantasai: For a badly-designed page, we have a problem.
  gregwhitworth: Depends on a11y tools they're using, what a11y
                 issues they have, plus how author designed the
                 site... depends on all kinds of things.

  fantasai: One very concrete problem we have is people using
            'order' for performance reasons, 'cuz faster than DOM,
            and end up trashing a11y.
  plinss: So we should make 'order' slower :)
  gregwhitworth: With performance, can only go so far, but then have
                 to teach authors better a11y.
  Bert: If we could come up with a way for users to get visual
        order, and also express why they chose that order, would
        give you information.
  fantasai: The problem is with authors who did't think about a11y
            and therefore don't care. So they wouldn't bother with
            some other extra effort in telling us.
  fantasai: The DOM order should be the order that I, as the page
            author, sitting next to you, would read it out to you as.
  gregwhitworth: Comes back to performance issues.

  Bo: My problem is people coming back to me that situation is bad,
      what can we do?
  Bo: People come to me using performance as an excuse for having
      things in the wrong order.
  fantasai: So can we do something about making the DOM faster to do
            this reordering?
  gregwhitworth: We're pushing performance already.
  fantasai: Maybe have an API that's closer to order's API, does the
            reordering in one step?
  TabAtkins: DOM reordering has strictly more work to do. have to
             not only reflow, but also adjust DOM and rerun
  TabAtkins: So will always be slower.
  Rossen: Would like to see exactly the use cases that are problems.
  Rossen: Nobody ever disagrees with "things should be faster",
  Rossen: but would have a hard time, especially for Flexbox when I
          don't expect so many items, why is DOM so much more
          beneficial for authors.

  gregwhitworth: Also useful to find use cases... some do visual
                 order, some do DOM order, but suppose e.g. login is
                 abspos to the top,
  gregwhitworth: because injected via script.
  gregwhitworth: How do we solve this problem in general?
  gregwhitworth: Technically, they would probably want the login
  gregwhitworth: It's worth solving that generic case.

  fantasai: Actually, you could optimize away lot of the selector
            matching, if you knew that you were moving within the
            sibling chain.
  Bert: A sort function would be nice. Sort according to some
  fantasai: Yeah, that'd be useful, e.g. for leaverou's pinned posts
            case. Could sort all things with .pinned selector to the
            front of the list.
  fantasai: Don't have to have separate calls for DOM removal,
            insertion, can optimize selectors, possibly even reflow.

  TabAtkins: People are using 'order' for reordering for performance?
  fantasai: Yeah, Bo is giving us that feedback.
  gregwhitworth: Even if reordering for convenience, it would be
                 good to have some use cases where that causes a11y
                 issue because meaning has changed.
  <fantasai> If using 'order' for convenience, better API for
             reordering would also solve the laziness problem :)

  TabAtkins: Maybe need a property that says whether to pay
             attention to visual order or DOM order.
  tantek: Problem is that the authors who have this problem are the
          ones who don't care (so won't do anything about it).

  plinss: So what do we do?
  fantasai: So one thing is find real-world cases where we have a
            problem, so we can understand better where the problems
  <ChrisL> element.pivotChildren(2,3);

  plinss: What about work for other WGs?
  fantasai: Yeah, should ask people to look into better API for
            sibling reordering.
  fantasai: Solves two problems.
  fantasai: One, 'order' is a really simple, easy, lazy way to do
            this kind of reordering. So having an equally simple API
            in the DOM would solve the "this is just easier for me
            to do in CSS than fussing with the DOM" problem.
  fantasai: Secondly, creates opportunities for UA to optimize a lot
            of things.
  fantasai: Not as fast as 'order', since as TabAtkins says, that's
            a strict subset of the work,
  fantasai: but having invariants and keeping in the tree will allow
            for more optimizations.

  TabAtkins: Maybe look at a switch for informed author...
  fantasai: If you're an informed author, wouldn't you be doing
            things correctly in the first place?

  fantasai: Should also try to find examples of pages which are
            correctly authored -- meaningful sequence is in the DOM,
            but visual order is different -- and a11y user still
            wants it in the visual order.
  Bo: Don't know that that's a real problem.
  fantasai: We were discussing this case before, where people wanted
            visual order despite meaningful order in DOM.

  Bert: Suppose I have some text that explains something.
  Bert: Section at the end says "for further info, see x, y ,z".
  Bert: I put it in the logical order in the DOM,
  Bert: but on the screen, I put the "for further info" on the left.
  Bo: That's considered complementary information.
  Bo: That's not important enough of a sequence to fall into this
  fantasai: Okay,
  fantasai: so to summarize:

  ACTION: bcampbell Get examples of broken pages

  ACTION: TabAtkins talk with WebApps about a reordering API
  <trackbot> Created ACTION-692

  TabAtkins: Possibility of a DOM switch?
  fantasai: I don't think that would help. People that would be
            aware enough / care enough to use it should be aware
            enough to do things right in the first place.

<br duration=15min>
Received on Saturday, 20 June 2015 12:43:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:15 UTC