Flex box and CSS

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