M5BP architecting a futuristic MODX

Manager with HTML5

MODX 2.X• Desktop First (inline styling, non–responsive)

• HTML Last (ExtJS owns the DOM)

• Ableism (mouse reliance, non-semantic markup)

• Aggressively Enhanced (white screen of death, 🚫 HTML)

😶

• Desktop First (inline styling, non–responsive)

• HTML Last (ExtJS owns the DOM)

• Ableism (mouse reliance)

• Aggressively Enhanced (white screen of death, 🚫 HTML)

• Really Awesome (creative freedom, community)

😁

MODX 2.X

• By tracing our technology stack back toweb standards we allow creative freedom in how it is progressively enhanced thereafter

• Extra Developers can use the tools of their choice(a less opinionated API)

• Themes configurable via CSS Variables makes theming more accessible

🎨

Creative Freedom

• mouse enabled

• sighted

• abled

• desktop

• sufficient data

🏃

Current Audiencerestricting access

2.X

• touch

• non-sighted

• disabled

• mobile

• cellular

🌐

Wider Audiencelet everyone in the building

2.X 4.X• everyone

Design Patterns• Mobile first (viewport, touch, bandwidth, battery)

• HTML–first (semantic, accessible, future–forward)

• Inclusively Designed (assistive tech, a11y preferences)

• Progressively Enhanced (interpretative, configurable)

• Searchable (filterable interface, search mode)

🙏

Primary Goals• Creative Freedom (empowering developers)

• Count the “Clicks” (monetize user experience)

• Everything in Reach (search everything a tap away)

• WCAG 2.0 Level AA (accessibility compliance level)

• VoiceOver Support (screen reader support, hidden text)

🙏

mobile firststicky bamboo

• A single tall scrollable column

• Collapsable sections(<details>)

• Sticky bar with jump to linksAnywhere is within reach

📱

HTML–first• Initially working within the

limitations of HTML makes for a more performant design

• Design challenges are solved semantically before visually styled or asynchronously enhanced <form action>

• Low ARIA usageARIA is Salt

👆

• HTML is interpretive

• JavaScript is declarative

• A semantic HTML document improves with time

• An non-semantic declarative document decays with time

👆

HTML–first

“Not including accessibility from the beginning is implicit

consent to incurringtechnical debt.”

—Karl Groves tenon.io

📉

Technical Debt vs Profit

Searchable• MODX Revolution introduced

the beloved uberbar 🎭

• Imagine taking the uberbar to the interface level 🤔

🔎

• Shortcuts to fully expand / collapse <details>⚡

• CTRL+OPTION+SHIFT+⬆

• CTRL+OPTION+SHIFT+⬇

🔎

Searchable

• Compatible with native browser search features 👏

• URL friendly/#uber?q=kansas

🔎

Searchable

Search ModeEntire Interface Opens

🔎

Desktop Uberbar

🔎

• Entire nav expands on :focus

• Can scroll passed it

• Dynamically filtered

Focused Uberbar Navigation Opens

🔎

“Try to refrain from allowing ableism into your designs.

Spend the same amount of time you spend on visual styles on

accessibility. #A11Y”—@mrktps

markup.tips

⏰😎

Inclusively DesignedNot a single critical features relies entirely on:• vision • style • mouse• script

🤘

Inclusively Designed• Enhancements are withheld until

they’ve been architected accessibly

• In other words, critical features exclusive to mouse users are not added until they are compatible with assistive technology

• This often leads to discoveries otherwise left unfound

🤘

HTML5 ContextMenus

HTML5 ContextMenus

Future Forwardready for a new precedent

• Writing future forward code isn’t just about supporting future browsers

• It is also about supporting more inclusive future societies such as Germany

• Companies with more than 20 employees are supposed to fill at least 5 percent of their positions with people with disabilities

🔮

Keyboard Friendly• Uses an accessible design pattern

discovered as part of a manage users concept

• no right click

• no modals

⌨

Battery Friendly• Follow the MAB Responding to Battery

Levels DRAFT

• Components switch between glutenous, modest, and fasting CPU consumption modes

• A more efficient interface is a moreaccessible interface(as it can be used longer)

🔋

Audible Profile (what’s the interface sound like?)

Not only is the interface tested cross–browser for visual styles, an audible profile ensures the

interface is semantic and usable for all users.

Like salt, ARIA is generally avoided and used in measured doses as a final seasoning if

needed.

📣

Screen Reader Friendly

Visually Hidden text audibly conveys what is otherwise conveyed visually to

sighted users

😎

HTML–first (look MOM, no AIRA)

Text is hidden with CSS so that when the CSS is removed, and the correlation between styled components is lost,

the text appears

😎

VoiceOver Support

🤘

VoiceOver Support (jump links accessible to keyboard & screen reader)

🤘

High Contrast Modes• Accessible CSS supports

white-on-black and black-on-white contrast modes

• Configurable by Operating or MODX System Settings (not a separate manager theme)

👀

High Contrast Modes

👀

Progressively Enhanced• Starting HTML–first means starting

interpretative first

• System Fonts, Emoji Icons, & modern browser features are weightless

• Make use of everything we can already on the device before spending on web fonts, icon sets, and scripts

🐣

• as enhancements are made make them configurable so they can be opted out ofor altered

• For example, icon sets can be opted out of and the interface falls back to emoji

• heavy web fonts are opt in

🐣

Progressively Enhanced

Progressively Enhanced Iconography

120kB0kB

Emoji Art is already there

• Emoji art weighs 0kB and is inherently accessible📦

• Emoji is the fasted growing language📈

• Icons improve legibility 👓

👻

Emoji–first Iconography

• Is interpretive🎭

• Will look different fromsystem to system😭

• Can be progressively enhanced (SVG, fontawesome, whatever)🚀

👾

Emoji–first Iconography

• Assumptions of ability are not made based detected peripherals or assistive technology

• Not all screen reader users are legally blind or even visually impaired

• i18n is easy to find

👥

Inclusively Designed

CSS Variables

🎨

• Append a stylesheet or <style> which sets CSS Variables tocustomize values

• WYSIWYG tools could allow end users to customize the styles without writingany code 🤔

CSS Variables

🎨

CSS Variables

🎨

CSS Variables accessible theming

🎨

Accessible Theming• No longer is an ExtJS, Sass, Grunt skillset

needed to paint the Manager

• No knowledge of CSS selectors needed

• As accessible as setting a few CSS variables

• *Variables can be adjusted WYSIWYG at the user level in Accessibly Preferences

(*WIP)

🎨

Count the “Clicks”• Each feature has a cost spent in measurable

user interactions such as clicks and key presses

• Persistent uber and jump bars keep search everything always within reach

🖱

• Important features accessible via VoiceOver rotor

⌨

Count the “Clicks”

Weigh In• Current baseline weight is 20kB including the

example HTML document weight

• 5kB CSS

• 6kB JavaScript

• Interpretive Code is already on the device

🏋

Spending Bytes• Additional declarative enhancements such as

webfonts can be configured to load

• Allow users to opt-in to expensive features(eg: default to emoji icons option for fontawesome)

• save-data when asked to

💰

Freedom of the DOM• No library or framework owns the DOM

🤘

Actively Developed

github.com/jpdevries/m5bp m5bp.herokuapp.com

⚒

👻

Emoji–first IconographyVoiceOver friendly

Cross Browser

Cross Browser

Cross Browser

Cross Browser