<html> for the win
Ever since this whole web browser thing really took off in the late 1990s, there hasn't been a web developer in email distance without issues of some kind. Everything is broken and we are constantly trying to fix it all without breaking everything else. Staying relevant amongst the pace of new technologies, workflows, and techniques is enough to take the wind out of anyone, even the “ninjas”. All of these amazing new tools are shiny and fun to work with, but not all of them seem to fit together :(
At Markup.tips we find ourselves in a bit of a pickle. We want to make awesome things with the tools of tomorrow but we also want anyone to be able to use them. Fortunately, we have found a way to have our cake and eat it too. Thing is, we must first travel back in time to around 1999, have some fun (maybe do a little partyin') and come back with the ability to take even the freshest tools and make them fit together with the interfaces we build.
“The tools we use to create the interfaces our users experience should have no impact on how many, or what kind of people can access those experiences.” — @mrktps
HTML 1st
HTML 1st means we design and test our components using… HTML first! Adhering to this process, we initially resist the fancy tools of tomorrow by starting components with web standards put forth by the WCAG Guidelines. (Let me tell you, the nights we study the guidelines and perform accessibility tests on our components can get pretty crazy…) We then use Tips and Tools to enhance these static blocks of markup into asynchronous web components of our dreams.
“If any page, component, or necessary interaction of our user's experience isn't accessible as plain markup we've failed.” — @mrktps
Go ahead, try out our Usability Preferences or navigate this site with JavaScript disabled. We have been ready from the get go. Markup.tips is a new project and a WIP but thus far we've:
- Created an Accessible Settings table
- Made some Markup Speak
- Stashed some Components Above the Fold
- Began an Accessible To-Do List Enhanced with
React - Implemented some Handy Usability Preferences
- Started Chipping away at a Flexible Media Browser
- Achieved a 99% Y–Rating
The great thing about starting with HTML and VanillaJS is these components can later be flavored with different drivers written using frameworks of the day like AngularJS, React or whatever else. Sounds maddening, doesn't it? It is, but I hope you will come along and feel free to stop and ask questions along the way.
We'll be tracing our technology stack all the way back to web standards in an effort to keep the core of our experience ubiquitous. Like children who enjoy the ubiquity of dumping their personal Lego pieces into a big communal pile so they can build cooler things, with web components as our individual pieces it will be exciting to see what we can build and how different people use the components we create.
Defining Accessibility
Specifically, Markup.tips defines accessibility by referencing versions 1.0 and/or 2.0 of the WCAG Guidelines.
WCAG 2.0 succeeds Web Content Accessibility Guidelines 1.0 [WCAG10], which was published as a W3C Recommendation May 1999. Although it is possible to conform either to WCAG 1.0 or to WCAG 2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web accessibility policies reference WCAG 2.0.
If you are building something new, the WCAG recommends using version 2.0 of the guidelines. So do we. However, at Markup.tips we like to track if our components comply to both versions of the guildines, one, or neither. We have a theory that if we start from an HTML 1st perspective (and maybe use a few clever tips) we will inherently comply to both in most situations.
The 99%
Yes, nearly all internet–enabled devices browse with JavaScript; Whoop-dee-doo. Usability of a web interface should never be put behind a script because scripts can be:
- disabled
- far away (take a long time to load)
- lost (not load at all)
- fatally broken
- conflict with other scripts
- expose users to security risks
While scripts can do amazing things to enhance components, any necessary interaction that is dependent on script can be as usable as a hammer in a wood shop but if it is not accessible in some way as plain hypertext it is not accessible; your door handle is mounted too high and not everyone can reach it.
HTML 1st & foremost
HTML 1st design isn't about how many users experience your .no-js interface anymore than architecture is about how often wheel chair access ramps are used. What matters is that they are accessible so that anyone can get in and experience the site. Whether that site is a physical building or a digital web app our responsibility as architects remains the same.
Furthermore, the level of semantics and ubiquity we achieve by starting off with accessible markup is worth the efforts alone. From an HTML 1st design perspective accessibility is just a happy accident. The components you'll find here simply could not have been developed without the possibilities and limitations of HTML up front and center in the designer's mind. As you'll discover we may need to use some crafty Tips but we'll get by with a little help from our friends. Accessibility is painfully simple in theory but can be really hard in practice; all the more reason to take it on together. No?
When you start with HTML 1st accessibility is something you are often rewarded with. Rather than having to work backwards like a foreman wiring a house after covering it in drywall you'll be able to pat yourself on the back for using a more sensible workflow from the get–go.
Markup.tips aims to give proof to the claim that there is a better way. There has to be a way we can make things work for everyone and still use all the new tools and enhancements we desire. Our ability to create the interfaces our users experience should have nothing to do with how many, or what kind of people can access them.
“
HTMLfirst design isn't about how many users experience your .no-js interface anymore than architecture is about how often wheel chair access ramps are used.”#a11y— @mrktps
Usability == Disability
Neither Enhancements to the interfaces our users experience nor the richness of the experiences themselves should have an impact on what kind of people can access them; therefore People === People.
Usability considerations like high contrasts modes aren't just for people with particular eye conditions; the person on the red-eye flight sitting next to your reader may appreciate them also. Supporting large font sizes isn't just for the hard of sight; the designer that enjoys sketching a comfortable distance away from their monitor while reading your post appreciates that feature. The ability to listen to a post rather than read it isn't just for the blind; the traveler enjoys listening to your posts on the go or even while driving. Using localStorage we can even allow them to choose different voices, so they can hear our website the way they want to. We believe responsive design is as much about adapting to ambient light as viewport width.
With all these things in mind we realize that in truth, we are all disabled all the time. So let us ask ourselves, why aren't we all designing our experiences accordingly?
Disqus This