├── LICENSE └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2015 JP DeVries 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | 23 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [1]:http://markup.tips/htmlftw 2 | [2]:http://markup.tips/settings.html#focus 3 | [3]:https://gtmetrix.com/put-javascript-at-bottom.html 4 | [4]:http://markup.tips/tips/making-your-markup-speak.html#focus 5 | [5]:https://css-tricks.com/why-ems/ 6 | [6]:http://markup.tips/tips/adopting-orphans.html#focus 7 | [7]:https://standardbeagle.com/the-frp-post-sxsw-part-2-no-average-user/ 8 | [8]:https://24ways.org/2013/grunt-is-not-weird-and-hard/ 9 | 10 | # Web Guidelines 0.1 11 | WIP. Best practices to use when building any web based experience. 12 | 13 |

Table of Contents

14 | 15 |
    16 |
  1. Preface
    2. 17 |
  2. 18 | Making Pages 19 |
      20 |
    1. Accessible
      2. 21 |
    2. Audible
      3. 22 |
    3. Configurable
      4. 23 |
    4. Enhanceable
      5. 24 |
    5. Legible
      6. 25 |
    6. Optimal
      7. 26 |
    7. Usable
      8. 27 |
    28 |
    3. 29 |
30 | 31 |

Preface

32 | As you author the web you should strive to create interfaces any user can access and use with ease. So how do you handle this responsibility? Relax, we'll walk you through it with these simple guidelines, but first you must understand a few things. 33 | 34 | Know that your HTML documents aren't written in stone; they are alive. The experience they offer changes as browsers and web standards evolve. What an exciting medium. You've chosen wisely. 35 | 36 | As you work through these guidelines your hyper–text documents will begin to make use of the evolving browsers that interpret them. As new features land in browsers your experience becomes lighter and more enhanced with time. That is the signature of a Front–End Developer, and you'll learn to sign it in your own way. 37 | 38 | Understand that accessibility is for everyone. All of us are users all of the time: we use handles to open doors, wheels to drive our cars, and utensils to eat food. Every _tool_ we utilize is something that gives us _access_ to our environment or the ability to complete a task which might otherwise have been impossible, and these tools – including tools you provide as a front-end web developer – define what kind of _user_ we are in a given context. 39 | 40 | With the many different ways to access the web, and the just-as-many tools to with which to do it, you must keep in mind that one person can be many different users on any given day. As our user shifts a high powered desktop and mouse–enabled computer to using a cellular low–power touch device, their method of access changes. If you don't design your UI for the right use cases, even the [fictional][7] "average" user you designed for will be left frustrated and locked out of your application. 41 | 42 | Herein is the crux of the web's accessibility issue: UIs that _do_ work for the user you target might be difficult or impossible for a disabled person to use. If you start your application with complete, meaningful user access in mind, it will be better for everyone. 43 | 44 | The thought of crafting experiences that can be used by anyone daunts you until you discover that accessibility isn't something you have to roll up your sleeves and add to your experience somehow at the end. Authoring pages HTML–first allows interfaces to be enhanced and a-synchronized in a progressive, rather than an aggressive manor. At ground–level we have an experience that anyone can access before we even start styling it with CSS and long before we enhance it with asynchronous scripts. 45 | 46 | Experiences you create are buildings entered, re-visited, and avoided by a wide audience of users. You'll build skyscrapers of experiences and from the wheel–chair access ramp on the first floor to the helicopter landing pad on the roof your users will enter the building all to find the same realization: while our abilities may very greatly and change with time we all justly deserve  access. 47 | 48 |

Making Pages Accessible

49 | We all know the desire to discover, process, and share information is a defining part of the human experience. So, who are we to decide who deserves that experience and who does not? Unfortunately as an industry we deprive groups of users the ability to access experiences simply because some of us are unwilling to build experiences a top semantic hyper–text. Think about that. Today people use web based apps and services to aid them with sensitive and important areas of their lives. If you find yourself drawing a line between the users that may access your experience and those that may not stop and consider these truths. If you are comfortable with shutting users out don't be surprised if fewer show up to see what your experience to offer as it progressively decays. 50 | 51 | > You are a user. So ask yourself, have you acknowledged your reliance on accessibility? 52 | 53 | You see, all users are passionate about accessibility whether they realize it or not. They might not know what a11y stands for but if you were to ask them to name their favorite devices and features sure enough you will find it is the accessible experiences that attract them. Let's take Siri for example. First and foremost, Siri is an accessibility feature. Siri is useful to the blind as well as the eagle–eyed parent trying to pull up directions while managing a van full of hyper kids who just wont their first soccer match. You see regardless of if the person has a permanent or contextual lack of ability they rely on accessibility. They rely on you. Know that when you build accessible experiences you build experiences that are better for anyone in any context. 54 | 55 |

FEAR

56 | Even those resistant to accessibility best practices gets frustrated when they try to access a non–responsive and therefore less accessible interface on their smartphone. They care about accessibility too; they just haven't actualized that in their workflow yet. This is likely because they are afraid of their false impression of what they think creating accessible experiences entails. 57 | 58 | I encourage you to allow yourself the understanding that fear is often merely: 59 | 60 | - False 61 | - Evidence 62 | - Appearing 63 | - Real 64 | 65 | So what is the false evidence assumed and why does it appear real to them? They assume accessibility must be "more work" than otherwise. This may not be their fault though. They may have tried to take a non–accessible experience and “make it accessible” without breaking changes long after it has been built. In that case accessibility is not only harder but may be impossible without making significant breaking changes. Imagine trying to install a shower in the middle of a building with concrete floors that wasn't plumbed for it. You'll need a wrecking ball or two. The key is to keep accessibility in mind from the beginning. 66 | 67 | Builders have construction codes that set standards for safety and accessibility. When a builder ignores these codes and refuses to do things like make the entrance wheelchair accessible that building begins to rot the community around it. The community isn't a place of inclusion anymore. That's why there are laws about these things. So why is it any different in the digital industry? 68 | 69 | Ironically, the hyper–accessible nature of the web makes accessibility standards more difficult to enforce and standardize than in other industries. It is much more approachable, and therefore accessible, to spin up a web server and start hosting a website than it is to say buy property, obtain the necessary permits and begin breaking ground. You can have the whole thing done in a few hours even with no experience and next thing you know, you are publishing to the web. Anyone can be a publish to the web. Your journey is to graduate from a web publisher to a web architect. 70 | 71 |

The Good News

72 | You've been wondering what the good news is in all this so here it is. Accessibility doesn't have to be any more complicated than you make it. If you [begin your experience by writing semantic HTML][1] then it already was accessible before you screwed it up by making it fancy with that one script library or whatever. If you jumped straight into JavaScript and didn't start with HTML the solution is simple. Start completely over, this time with an HTML–first workflow. HTML is accessible so make sure you start with it. 73 | 74 |

Authorship is Everything

75 | JavaScript is amazing. It gave us the ability to liven what was once a static and synchronous DOM. Modern JavaScript populates and oversees the DOM for us so we stop worrying about it. Here's the problem. The moment you loose authorship of the DOM to scripts you stop architecting the web. Scripts attempt to create a well architected experience but they fool no one when they don't load or a misplaced semicolon breaks your entire experience. Don't be fooled. Remember that as an architect of the web you are responsible for every state of the underlying DOM which makes up the experience of your user just as the Graphic Designer is responsible for each pixel of their design. 76 | 77 |

The First Byte

78 | Whenever you begin authoring a page for the web you should have one thing in mind: The first byte. The first byte is really the most exciting byte if you think about it. It's the moment a connection is made, and someone somewhere decides to start downloading your document. Then they wait. Hopefully not for long, but either way they are waiting for your experience! What does this experience feel like for your users? Does the page begin loading immediately as a legible text document before the assets loads or is it a blank white screen until everything has loaded and the scripts have executed successfully? Does your infinite-scroll one–page website have a pagination component available for .no-js users to access content or does it just stop at nothing? Is that fancy custom designed select box actually a better user–experience than a native `