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