Reading Time: 3 minutesMarc Marc posted a poll on the WCAG A11y Professionals Facebook page to gauge opinion of frameworks v. native JS and CSS. I added the following sermon from my pulpit as the topic resonates with this week’s, Taking Control of Agile UX presentation by Jared Spool of Center Centre. Jared restated my belief that our whole team is 100% UX.
Jared’s proposition is:
“While business outcomes are important, the only way we truly succeed is if everyone is focused on building products and services that improve people’s lives.”
Designers, developers, and engineers can focus too hard on the business tasks that their personas perform. They don’t plan for the scenarios people overcome to access those tasks.
Vanilla HTML content is largely accessible out of the box. It is how we configure and deploy it that creates the barriers. I learned that even in the hands of an idiot framework components can be inclusive and repeated the message that creating inaccessible components makes you a bad person.
My Sermon
My Facebook response to Marc Marc is repeated here for future reference and reflection. It comes as no surprise? I don’t blame the frameworks as much as the people creating and deploying them to an ableist World. That’s not charity, it’s an expectation that frameworks enable inclusive design.
“Interesting question as I am often criticised for my dislike of frameworks. (I’m UX and content – not graphicist). The truth is that the contemporary frameworks are not (all) in themselves evil – the people commissioning or configuring them for their apps?”
For example, I attended a demo of a frameworked web project that used fixed font sizes updated with breakpoints based on viewport widths (not by device). I called out a scenario of our user completing their task with our app on one side of a desktop screen for reference and an active app on the other. On their narrowing the (our) viewport, we would reduce the font size on the same device for which we intended a larger size. Mad. Response: “That’s not our focus”.
We CAN configure the framework to produce a fully inclusive experience of app components. Our common medium regardless of JS or CSS is HTML and we share a common editorial intent and business need, too. We MUST involve and include our devs and engineers in our Inclusive experience vision to specify and enable their accessible design for whatever technology they exploit. No more handing off dumb wireframes and devs churning out a reproduction like secretaries.
For example, within any (?) framework we can interrogate a parent container’s headline level and update our child card component’s headline one level less and avoid the usual ‘missed level’ issue found across our Web. It’s only JS and playing around the DOM. Why don’t we?
Evil? Lazy? Ignorant? I know we can do better – by design.”
Are We Alone?
Marc Marc clearly shares my disdain for the added bloat and complexities that frameworks can bring to the build and maintenance. The, “Cult of Complex” as he and A List Apart describes it. Probably full of little dev’ls 😀
So, are we alone? How many digital production staff are with us? 15 years into this journey and I review the same dog-poo results spewed out by this, this “Cult” and its ableist membership. (Sigh).
Root Cause
Is the root cause our talent recruitment? Has the visual domain so overtaken digital design and production that we are left with and celebrate unintentionally ableist products? Why must we even think to employ “accessibility experts”?
I am continually disappointed when engineers and developers work from static “wireframes” without user-centered design. Why don’t they know how to deploy ARIA, or even how to write semantic HTML? Why can’t they just send the wireframes back and ask for a responsive solution already planned for screen reader consumption? (Another rant).
There’s hope. The “trend” toward inclusive design is gathering momentum and we are slowly recognising the workforce and education centers that refuse to adapt. Visual design is important to the experience yes, and not to everyone. UX is more than skin deep!
One day, we won’t even need to talk about accessibility and WCAG will be inclusive.
Summary
I think we should campaign for an end to the DIV and SPAN vomit these bells, whistles, and other dog poo-inspired frameworks promote. That’s not an end to frameworks. It’s an evolution toward our deployment of them as inclusive and useful HTML. That’ll reassure enterprises believing the Internet can’t work without them.
That’s our basic Human Right, after all. (Refer to Convention on the Rights of Persons with Disabilities (CRPD) Article 9, 1.b).
Let’s start by promoting the whole digital production team and enterprise leadership as designers. Or am I shifting the blame? I’m learning too, after all 😀
Comments?