Re: Flex box and CSS

Janina is supposed to respond to the CSS working group based on input from
the working group. We will find out more today.


Rich Schwerdtfeger



From: Michiel Bijl <michiel@agosto.nl>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: public-apa@w3.org, fantasai <fantasai.lists@inkedblade.net>, Bo
            J Campbell/Los Angeles/IBM@IBMUS
Date: 01/13/2016 10:44 AM
Subject: Re: Flex box and CSS



Excellent write up. What are our next steps? Or what should our next steps
be?

—Michiel

On 13 Jan 2016, at 17:03, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:



      Janina asked me to write up why the FlexBox accessibility solution
      "don't do that" is unacceptable.

      Flexbox is a very powerful solution that developers and designers
      want to make use of - including in IBM as it allows the author to
      visually restructure the order of the presentation of content without
      a very expensive restructuring of the DOM. The solution proposed in
      the CR draft is to say "Don't do that."

      I work at a large corporation with over 1000 products. Designers find
      out something works visually and they say they are done. Very seldom
      do they pay attention to the "don't do that statement". What then
      happens is the accessibility people are having to go in and tell them
      that they can't do that. What then happens is people of disabilities
      are singled out as it places a burden on the developer and the
      accessibility people appear like the grim reaper. The most gross
      example of this was WCAG 1.0 where the accessibility community said
      don't use CSS and JavaScript. Developers were forced to create
      alternative content, compromise the user experience, and from a
      personal perspective cost IBM millions of dollars to create an
      alternative solution - ARIA. This expense was magnified by all the
      W3C members who invested in bringing it to industry adoption level.
      Where would the web, today, be without this investment.

      At the California TPAC, 2 years ago, PF met with Fantasai and other
      members of the CSS working group. We made it clear that it was
      possible to make CSS Flexbox accessible. What was necessary was that
      they include a feature that stated that the flexbox order represented
      a meaningful sequence. What that would trigger is:

      - The accessibility tree would be constructed in the order of the
      Flexbox order. If flexbox styling was activated inside another
      Flexbox section the accessibility tree would be constructed
      accordingly. So, it is recursive.
      - The tabindex sequence would follow the flexbox order. So, what
      would happen is you tab to through the DOM tree until you reach a
      flexbox box (first in the sequence). You would tab to the first
      focusable item in that sequence and follow the normal tab order
      within the box until you tab out and reach either the next box in the
      sequence (and repeat the process) or tab out to first element in the
      sequence in the DOM following the Flexbox.

      So, this is doable and it highlights a much more serious issue with
      CSS which is not addressing interoperability with assistive
      technologies. The HTML, SVG, and ARIA working groups all do this yet
      one of the most important standards sets within W3C does not. In
      fact, they also do not address CSS content injection. None of this
      content is available through the DOM but it can be through platform
      accessibility APIs. There is no conformance specification in CSS that
      addresses this issue (interoperability with assistive technologies).

      I went so far as to put an engineer in the CSS working group to put
      focus on the FlexBox and other CSS issues but the only thing that
      came out of this was a "Don't do this" or "punt." ... IBM spent money
      and time on this.

      I do not want to see a repeat of what happened with WCAG 1 but I see
      history repeating itself again. Even WCAG 2 is forced to prohibit
      content injection for accessibility. However, with the growth of the
      mobile web we need CSS to address performance issues.

      I find it extremely discouraging that after 2 years of this being
      raised all the CSS working group can muster is a "don't do that." We
      need an inclusive web and we need to ensure that technologies coming
      out of W3C are accessible from the get go.


      Rich Schwerdtfeger