Book Review: How To Become A Web Developer: The Career Changer’s Guide

One of the most difficult to pin down topics and titles of the last couple of decades is to define oneself as a web developer. What exactly does that mean, and what skills does one need to know to become one in this day and age?

Julie Torres, one half of the "Code Crush" podcast, has done what I feel is a good job distilling that into an 86 page book titled, specifically enough, “How to Become a Web Developer: The Career Changer’s Guide”.

Starting with the Prologue, Julie describes the specific circumstances that started her on this journey. With a softening job market during what we now refer to as “The Great Recession,” Julie describes how she moved from being a bank teller to become a junior developer. Her point in sharing this story is to make clear that you don’t need an advanced degree in computer science or have lots of history as a programmer to make the shift into doing web development. This book pledges to help you make that transition. Does Julie deliver on that promise?

Chapter Zero: Prepare for the Journey 

Julie sets out some basic markers to help you make the most of this journey including the idea of starting your job hunt while you start your web development journey. Counterintuitive, but makes good sense. Looking at what is out there, what is required and what skills are consistently being asked for is a great way to tailor your learning path. Utilizing Meetup groups and other resources will also help. Determine how to measure your progress, whether that be a way to check in with an online community or work with a specific mentor or group of people. In this day and age, showing goes a long way and having resources you can demonstrate to show your skill can be a big boost in this process. Code repositories and websites in the cloud to show your work can help tremendously. Don’t be concerned with whether or not you “measure up” to others out there. At the start, you won’t but your journey is yours and that’s what matters.

Chapter One: First, Choose Your Goal

Front End, Back End, Full Stack, Mobile, and a reference to QA by way of automation. This particular part touches me because I am primarily a tester in my work role, but many web development skills are still part of my daily repertoire. I’m glad Julie include testing on the list because many developers do actually make a decision to look at testing as a primary responsibility. The point is, deciding where you want to place your efforts will make a big difference in what you study and in what order. Likewise, there’s no rule that says you have to be permanently committed to any one goal, right?

Chapter Two: Choosing Your First Programming Language

Languages have a lot to do with the applications or environments you want to work on. Java is now a perennial favorite of many organizations because it is ubiquitous. Large corporations use it, Android devices use it, and there’s a large ecosystem for the language. It’s a wordy language, true, but the benefit is that there’s a lot of examples out there to look at and review. JavaScript is a language that has spawned numerous libraries and smaller ecosystems of their own. When you see people asking about Angular, Bootstrap, jQuery, React, etc, those are all specialized JavaScript frameworks. PHP is a great language specific for a large number of existing sites. Python and Ruby are also popular languages that also run in web stacks (Django and Rails, respectively). What you use will depend a lot on what you ultimately want to work on. If your dream job is making iPhone apps, you may want to take a look at Swift. The key is start with where you want to go and then pick what you will work with.

Chapter Three: Paths to Learning

You may be thinking “I don’t have a Computer Science degree” and that’s totally fine. Many of the best developers I’ve know have degrees in completely different disciplines. Whether you choose to go to college, do a coding Bootcamp or use an online resource like freeCodeCamp, the point is you have to put in the time, get frustrated a little and work through the issues you will undoubtedly face.


Chapter Four: What Skills Do You Need?

The foundational skills necessary are surprisingly small. Yes, it helps a lot if you can touch type and do so at a decent speed. Knowing how to use a computer or mobile device well is important especially if you can understand how to open, edit, move and manipulate files and directories. Understanding fundamental math skills and having a good understanding of the scientific method is also very helpful (not mentioned in the chapter and were I to suggest any additional basic skills to include I’d strongly suggest that one ;) ). From there, you will need to learn about how to use the command line of your chosen operating system(s), understanding the basics of HTML and CSS, using a version control system to chart your progress and, on occasion, back up and go to an earlier time to do something different, and understanding of how the Internet works (TCP/IP and HTTP, for example). From there, databases, return codes, error handling, and flow control of programs will come into play. Sounds scary? In truth, it’s fairly straightforward but the devil is in the details. Again, the key here is to understand what you want to do and then plot the course to get there. It will require a fair amount of knowledge buildup and experimentation, as well as false starts and frustrations. Julie goes into some detail in this chapter about the various frameworks available, sample programs and applications you can develop and ways to display them so that people can notice your progress.

Chapter Five: Things to Ignore (at Least For Now)

Depending on what it is you wish to work on, there may be many skills that will be important later on, but that you do not need to worry yourself with at the start or even in the first few years of your progress. You may never have to get familiar with topics like binary, specifics of computer hardware, or the underlying computer networking infrastructure and communicating with the lower layers. There is a list where there are things that will be helpful to understand later on and while I agree with much of the list, I have to take issue with testing being considered not so important. Personal opinion time, I wish more developers would put testing and a testing mindset at the forefront of their learning. It will help encourage more developers to see what they are developing, to begin their work with questions of quality and experimentation in mind and to ultimately help deliver a better product to their users.

Chapter Six: Learning Resources

This chapter includes a list of resources to help fill in key concepts and skills you may need. Many of them are completely free, while some have a small cost associated with them (small is relative, of course). Julie also includes a variety of blogs and websites that can also be helpful (I too am a fan of the Tuts sites and encourage people to check it out).

Chapter Seven: Staying On Track

The chapter starts out with this quote:

"Learning to code is more of a motivational challenge than a technical one." -- Quincy Larson, Founder of freeCodeCamp

On the whole, I agree with that. How we keep ourselves motivated is important, and finding our true motive is also critical. Do we want to make more money? A good place to start but may not sustain us in the long run. Chose methods that will help you stay committed to your goals, such as participating in meetups, hackathons, or other projects you can do with other people to get feedback and feel connected to what you are doing.

Chapter Eight: Career Goals

Just as important as what you want to do is where do you want to do it? Do you want to work for large companies or would you be interested in working for smaller organizations? Understanding the tradeoffs for each is important. Large companies can have great infrastructure but very defined ways of doing things. Smaller companies may be more chaotic and struggle with getting to profitability but the sky's the limit with where you can potentially get involved. You can also work with various employment agencies on a contract basis to rotate jobs and gain experience. Once you have a good enough foundation, you could perhaps hang up your own shingle, so to speak, and freelance. Don't be surprised if you find yourself doing a little of all of that, especially in the first few years.

Chapter Nine: The Job Hunt

Remember that advice in Chapter Zero? Here's where doing all of that this whole time should start helping. If you have been communicating with a variety of people along your journey, they may take an interest in what you have put together and speak with those in their organizations that have a hand in hiring. Resumes still matter at a lot of places, but they are taking a backseat to demonstrable ways that you can show your skills. In this day and age, tools like LinkedIn, GitHub, SlideShare, and a blogging platform can do a lot to boost your visibility as well as have lots of examples of demonstrable skills. Additionally, connect with people and communicate with them. The key here is to start this process well before you need to look for a job so that when you are ready, you have already identified people who you can communicate with. Another bonus is that, if you do this regularly, they will likewise know you are ready and can help you find your next gig.

Chapter Ten: Interviewing

Whether it be initial phone screens, in-person general interviews or technical interviews, you will be judged based on how you respond. Having a good handle on a variety of skills and being able to explain them will go a long way in helping you with these interviews. You may be given a coding challenge to complete, either on-premises or as a take-home assignment. Practice a few of these so that you can feel confident that you can do them if given the opportunity or request. This chapter has a lot of practical advice for specific technical interview questions as well as how to negotiate for salary.

Chapter Eleven: Building a Successful Career

Once you get that first job, realize that it's the bottom rung of a new ladder. There's still much to learn and many areas that you can get involved if you choose to. Pay attention to sticking points in the organization and see if you would like to tackle those challenges. See where the rest of the market is going and if you feel that you are ready to pivot if market forces change. Most importantly, never stop learning.


Along with all of these chapters, Julie shares many personal anecdotes of her own journey that has brought her to where she is today. These vignettes help the reader see what choices she made, both for good or ill, that have helped inform the rest of the text.

BOTTOM LINE:

For those who are looking for an in-depth guide to learning how to become a web developer, this book doesn't cover those except for skimming the resources needed to accomplish those goals. This is much more of a field guide to allow you to safely manage the trek and it is filled with a variety of markers that you may find interesting along your journey. As the title says, this is a Career Change guide, and those focusing on the "How To Become a Web Developer" are missing the key in the subtitle. This is a guide to navigating a career change. To that end, it meets its goal admirably.

Accessibility and HTML: Accessibility for Everyone: Long Form Book Review

As seen in my last few entries, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

ACCESSIBILITY AND HTML

This is the payoff point. With solid, well-structured HTML, most of the struggle to make sites accessible becomes very simple. That's it! Oh, wait, you want to know what that actually means, don't you ;)? Well of course and that's the meat of this chapter.

Many of us learn the basic HTML tags and we think that's all we have to do. Not much to it, except for the fact that there are lots of parameters for nearly every tag, and understanding those parameters can help immensely in making sites more accessible. Turning off CSS in your browser can be very informative, as well as jarring. Pretty sites get reduced to a listing of text and spaces only and with it a much clearer idea of how your pages are actually structured and it also shows how a screen reader would walk through it. If you find yourself scrolling through a bunch of stuff to get to the main content, imagine how it will feel to a user utilizing a screen reader waiting for it to "get to the point already".

Being effective with headings can do a lot to help structure your page in a meaningful way. Think of an outline for a paper or presentation. You put certain elements at those levels for a reason, right? Make sure to use your heading tags the same way (h1 - h6, etc.). Lists are also helpful to break up the content and make it more readable, so use the proper list elements (ol, ul).

Forms are a prime location for people to add extra code to help make sure that the user is putting the right information in. The downside is that, for many using accessibility tools, these enhancements will be confusing at best and completely bypassed at worst. Also, while it's a common convention to put a red asterisk to mean that information is required, having a tag call out that it is required, or literally spelling it out is better.

For many users, the keyboard is not just the primary input tool, it is the only input tool. Therefore, it is wise to use conventions that are well known and understood. Be careful making your own conventions or overwriting long standard actions.

Skip links are found at the start of many documents. Since users may be familiar with the content they are after and know how to find it, presenting them with a navigation bar they have to address each time can be both training and time-consuming. Putting a skip link in means the user jumps over the navigation elements and gets right to the main content on the page.

Tab order is critical, so make sure that users can get to the content they need in as few steps as necessary by using the (tabindex) option.

It should be no surprise that HTML that is generated from WYSIWYG editors is often literal, overly verbose, and overloads each tag with meta details that are better put elsewhere, so paying attention to how your code is formatted is important. Additionally wherever possible, try to keep structural aspects in your HTML and move the style elements, wherever possible, to CSS.

Another important aspect to consider when writing HTML for accessibility is the notions of "Progressive Enhancement and Graceful Degradation". In a nutshell that means "start from a basic framework and add the aspects and elements that allow for the specialized tools while keeping the base experience similar for all users. Likewise, Graceful Degradation is the idea in the opposite direction. If something fails or doesn't apply due to a user's method of access, don't just shut them out. Instead, make it possible to view as much of the content as possible, even if some of it is unoptimized.

If' you've been around Accessibility any significant length of time, it's likely you have come in contact with WAI-ARIA tags. WAI-ARIA stands for Web Accessibility Initiative—Accessible Rich Internet Applications and is helpful in allowing for certain tasks to be described in a more effective way, beyond what HTML and CSS ever intended. If you have ever heard a screen reader counting down and declaring the percentage progress of a file being downloaded, odds are that behavior is being defined in an ARIA tag.

Each of these areas is described in more depth, but they are not comprehensive breakdowns of each. As I will mention again when I do my summary review, Laura is not writing a "what" or a "how" book as much as she is writing a "why" book. As the title states, this is "Accessibility for Everyone" and that goes beyond the role of the programmer trying to make the site. The nuts and bolts are important, but the philosophy is even more so.

KEY TAKEAWAY

Meaningful HTML is the key, and to make HTML meaningful, we need to understand what it's best suited for and when it's better to let something else (CSS, ARIA) step in and take care of things like styling and more advanced interaction. Structuring documents effectively and understanding how to place the most important information up front helps everyone, not just those in need of assistive technologies. Also, it's good for the soul to see what your site tells you without the eye candy present. If it's a mess and hard to distinguish what is what, that's exactly the experience users who need assistive technology will have.

Spread the Word: 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

26. Find an accessibility issue on a website, and report it.

Since Blogger is my tool of choice for hosting TESTHEAD, it seems only fitting that I look to it to see what I can do to help improve its ability to be a better accessible platform or, barring that, at least accessible as far as what I can actually do to enhance it.

Using WAVE, the following error was the first to pop out:

Errors

Document language missing

What It Means

The language of the document is not identified.

Why It Matters

Identifying the language of the page allows screen readers to read the content in the appropriate language. It also facilitates the automatic translation of content.

How to Fix It

Identify the document language using the attribute (e.g., ).

The Algorithm... in English

The attribute is missing or is empty.

The nice thing about Blogger is they have a "Send feedback" button in the lower right-hand column for the Dashboard, so submitting issues is easy, as well as with screenshots.

Curious to see if in the future we see this enhanced :).

What is the Law? 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

24. Learn about accessibility law in your country.

I live in the U.S.A., and therefore, while WCAG 2.0 is the guidelines I aim for, we usually refer to "Section 508" or features being "508 Compliant" because that is a section of the Rehabilitation Act of 1973. Actually, there are two areas in the Rehabilitation Act that relate to disabilities. The first is Section 504, which declares that the act "prohibits federal agencies, programs, or activities from discriminating and requires reasonable accommodation for qualified individuals with disabilities." Section 508 declares that "agencies must give disabled employees and members of the public access to information that is comparable to access available to others." A basic checklist of Section 508 compliance can be seen by clicking on the link.

Notice anything interesting there? Did you see anything mandating that Accessibility is the law everywhere? Nope. Just in the services and the fund allocated for them by the federal government. Is there a strict standard? Again, nope, but Section 508 by virtue of being a policy of the federal government, and with the sheer volume of software seats that the federal government provides, can carry a lot of weight in regard to the design decisions of companies.

I know for a fact that a large agency of the federal government looking to purchase a lot of software from my company was what initiated a thorough review of Accessibility requirements and areas that needed to be updated in our product so that they would buy it. The dollar amount of that deal most certainly played a part in why we undertook a large-scale retrofit of our product to meet Accessibility standards, and again, the standard we measured for that purpose were the guidelines as described to meet U.S. requirements. To meet the broader WCAG 2.0 requirements means we still have a distance to travel still.


For a nice breakdown of what USA Laws do and don't cover, see http://webaim.org/articles/laws/usa/

Mental Hopscotch: 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

23. Find missing semantic information (e.g. headers, landmarks, links, and buttons).

Yesterday, we had a look at Semantic HTML and what it is. Today, let's take a look at how well my blog actually uses it (yep, we're picking a fight with TESTHEAD once again :) ). That means, indirectly, I'm also calling out Blogger as to the way it lays out its pages since TESTHEAD is hosted on Blogger.

As I open the source and try to see what each page would be showing me, the fact is, most of the layout for Blogger is not using Semantic HTML in any easy to see manner. Almost everything is a div, with a hierarchy in CSS that is a bit hard to decipher on first glance.

A quick look at the div listings. They are named, but not using the examples highlighted yesterday.

Here's a look at the navigation section, which does use a header tag:

Granted, Blogger is a template system, and there is a lot of manipulation required to make those templates work with individual customization, so a semantic design may be difficult to pull off, but I wonder if I could work some of the options into my individual posts. I will give it a try tomorrow for comparison.

In a Manner of Speaking: 30 Days of Accessibility Testing

The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.

The song title puns continue, but this was a stretch. I know this one from Martin Gore, but it's a cover of a Tuxedomoon song. You're welcome ;).

22. Learn why semantic HTML is important.

Put simply, Semantic HTML goes beyond the literal markup of an HTML page and uses tags that have meaning in and of themselves.

To borrow from W3Schools explanation of semantic elements:

A semantic element clearly describes its meaning to both the browser and the developer.

Examples of non-semantic elements:  "div" and "span"  - Tells nothing about its content.
Examples of semantic elements: "form", "table", and "article" - Clearly defines its content.

Examples of semantic HTML elements (W3Schools).

HTML 5 has taken this a step further by making it possible to structure documents by using more readily understandable terms. Tags such as "article", "aside", "details", "footer", "header", "nav", "progress",  "mark", and "time" all give clues as to what the element is meant to represent, much more quickly than a general "div" or "span" will tell you.

By using Semantic markup, we don't just make pages that are easier for users to understand, we make pages that are easier for developers to understand as well.

Book Review: Practical Web Development

Does it seem like I am starting off a lot of my posts lately with an apology? If so, it's because it feels like I've fallen off the wagon of things I should be doing (and stopped doing) because life interfered. One of those areas is the book reviews I pledged I would do more of this year. It's gotten so bad that I had to basically tell a number of publishers to hold off on titles they send to me until I can get through my back log. Don't get me started on the figurative stack of Python books I'm looking at right now (I can't say literal because they are PDF's, but trust me, there are a lot of them!). Also, as many of you well know, I do not do short reviews ;).

Still, the best way to get back on a horse is to just climb back on, so without any further ado...

At this point in time, programming for the web is a multi-faceted endeavor. There are so many choices and approaches that can be used, and technologies that can be called into action, that it is impossible to master them all. Gone are the days of basic HTML and some CGI scripts being all you’d need to deliver a web experience. Don’t get me wrong, there are still sites out there that are basically this simple, but they are outnumbered by sites that offer much greater interaction, customization and the ability to display on multiple platforms. To do that effectively, more is needed.

The challenge with most web development books (or programming books of any type, actually) is that it takes several hundred pages to cover everything needed, or the books end up being lean and abstract, with the reader having to do a lot of their own research and tinkering to create examples of their own or make the samples provided work.

"Practical Web Development" by Paul Wellins (Packt Publishing) takes a slice down the middle. It doesn’t pretend it will be able to show you everything in great detail, but it does looks to give some "practical" examples with the most common elements and some exercises to work and build on. Wellins progresses from basic HTML, CSS and JavaScript to using PHP, MySQL jQuery, AJAX, History API, XML & JSON, MongoDB, Responsive Design, Foundation framework and Node.JS. Make no mistake, that’s a lot of ground to cover in 276 pages.

So how well does Paul traverse this formidable mountain range of topics?

Part One of the book focuses on the central elements of a “stack” that allows a web site to exist in the first place, and gives an overview of the technologies that work with that web server.

Chapter 1 covers THE WORLD WIDE WEB, specifically where it’s been, where it is, and where it looks to be going. It’s a whirlwind history lesson that covers a lot of technologies that we take for granted today. For the purpose of the book, the emphasis is being placed on HTML, CSS, JavaScript and PHP, with a back end database using SQL. Therefore, up front, five “languages” need to be learned to be effective and use the book. Fortunately, the amount of each language that is needed to be learned will grow with each subsequent chapter, so you get a chance to use each of them as the book professes.

Chapter 2 focuses on the basics of HTML and the most common tags used for markup of pages. Rather than give an exhaustive run down of all the tag elements, Paul gives us the ones that are the most useful and likely to be used when developing a basic site (headings, paragraphs, links, form elements tables and divs, which are best described as self contains rectangles of HTML). Paul also makes the distinction between the structure of a document (which is done with HTML) and the styling touches, which are handled in the next chapter.

Chapter 3 covers what Paul feels are the most useful aspects of CSS, which is all about the syntax that affect the overall look and feel of your pages. The structure of the box model is central to CSS and being able to manipulate the data in a variety of boxes (often the aforementioned HTML div’s) helps to keep the style elements both contained and optimally configured. A recommendation for the use of Firebug or Development Tools in your respective browser is also recommended, as there are a lot of possibilities within CSS and ways to apply them.


Chapter 4 takes us on a tour of JAVASCRIPT with a dose of Programming 101, and builds on some of the basic building blocks of of all programming languages while focusing on the core elements that make JavaScript useful in web pages and applications, specifically as a client side programming language. Variables and variable declarations are covered, manipulation of strings and numbers, operators, control flow, functions, and objects all get a brief but focused examination. The final part of the chapter talks about using the Document Object Model (DOM) and ways to work with objects, properties methods and events. Again, it’s a high level view, but one in which you feel like you can relate to what’s being presented.

Chapter 5 introduces PHP, which is a language designed specifically for server side interactions. Again, like the previous chapters, this section focuses on what most users would need to make something work on the server using PHP, not a complete rundown of the syntax. This chapter also goes through the basics of what you need to do to check if your web host is set up to support PHP and what to do if it isn’t.


Chapter 6 adds more about PHP, specifically in conjunction to working with a MYSQL database. The chapter starts with a basic understanding of databases in general ,and then MySQL in particular. It introduces the way that databases work and how MySQL fits into the web stack. phpMyadmin is covered as well, which allows you to administer a SQL database via the php utility. It also walks the user through several commonly used database commands and fundamental queries.

Part II of Practical Web Development aims to help us break away from the model of multiple pages where a few will suffice, and to get away from static pages to those that are more interactive, dynamic and responsive to the platform it is being displayed on.

Chapter 7 covers JQUERY, which is a JavaScript library that emphasizes a small footprint. It uses CSS selector style syntax that specify DOM elements. Again, the coverage is not exhaustive, but it give enough to show the general approach to using jQuery as part of your page development and the most likely to be used aspects of the library.

Chapter 8 focuses on AJAX (Asynchronous JavaScript and XML) which is really a handful of different techniques that allow for data to be retrieved in small pieces without requiring the entire web page be reloaded. jQuery has several methods that allow for AJAX to be used. $.load and $post both allow for portions of the screen to be replaced with fresh HTML, dynamically generated or programmatically placed.


Chapter 9 covers THE HISTORY API, which becomes very important when you start creating a site that is based primarily around a single page. rather than direct a user to the previous site they were on before coming to ours, the History API allows the users to navigate back to states of the page, or to allow for a bookmark URL to represent the state of the page bookmarked.


Chapter 10 focuses on using XML (extensible Markup Language) and JSON (JavaScript Object Notation) as data formats to be used as an alternative to HTML.

XML files can be seen as small databases. XML Schema defines the structure XML files, while XSLT creates stylesheets for converting XML into different formats. SimpleXML allows for paged to be created and processed using PHP. JSON is a lean format that gets processed like JavaScript objects in the browser, and therefore requires much less overhead.


Chapter 11 introduces us to MONGODB, which is a type of NoSQL (not relational) database. It’s more readily known as a document database, and it stores JSON objects that are grouped into collections. Web applications are capable of communicating with the MongoDB using PHP.
.
Part Three of the book moves away from the underpinnings of the technology and deals with methods that help the loo and feel of the users experience, regardless of the platform being used.


Chapter 12 focuses on MOBILE FIRST, RESPONSIVE DESIGN WITH PROGRESSIVE ENHANCEMENT (go ahead, say that ten times fast ;) ). The key idea is that, based on the platform it is being displayed, the page will dynamically tailor itself to display optimally for that device. Desktops, tablets and phones have radically different screens and needs, and Responsive Design aims to help with that. One of the key aspects of this chapter is to encourage you to focus on mobile development and display first, and then work back. Additionally, another JavaScript library called EnhanceJS allows for different experiences to be displayed depending on the browser being used or the platform accessing the content.

Chapter 13 introduces FOUNDATION – A RESPONSIVE CSS/JAVASCRIPT FRAMEWORK. The idea behind Foundation is that it lets us focus on developing a site without having to reinvent the wheel on the responsive part. By using a grid system, you can determine how many areas can be used depending on the size of the screen, so that the site expands and reformats based on the grid. Foundation also includes a number of UI enhancements that make it easier to put together navigation, image display and other details that make interacting with a site easier based on the available real estate.

Chapter 14 closes out the book with an introduction to NODE.JS, which is, at its core a fundamental break with all of the rest of the web development options discussed in the previous chapters. Rather than require a whole host of technologies, everything can be written within Node, which then translates everything to native JavaScript (and by extension HTML, CSS, etc.). This can be done using the Express framework, which is described in basic detail, and the idea of templating (which is what PHP does), using handlebars.js.


An Appendix section describes BOOTSTRAP - AN ALTERNATIVE TO FOUNDATION. The same exercises Paul described in Chapter 13 he tackles here, but uses Bootstrap.JS. It meets a similar goal, i.e. making a mobile-first, responsive site without having to reinvent the wheel to provide the responsive part.

Bottom Line:

The title of the book is Practical Web Development, and a special emphasis needs to be placed on the “Practical” part of the title. Paul has strived to make a book that is accessible, easy to follow, and lean enough to be usable without getting the reader lost in the weeds. I’ve long been looking for a book that would be a soup to nuts title, one that could be the starting point for someone to start with developing for the web, and have a single source to get up and running. Is this that book? It’s pretty darn close! There’s lots of additional areas that could have been covered, but to his credit, Paul has made a title that hits the high points, and a few divergences that are interesting if not mandatory. For a lean and straightforward primer on modern web development approaches, this is a great place to start.

Book Review: Build Your Own Website

With the "Humble Braniac Book Bundle" still underway, I felt it only fitting to keep the trend going and review books that are geared towards kids and those who want to have a quick introduction to the worlds of programming, web design and engineering. My daughter and I are exploring a lot of these titles at the moment, and one that caught my eye was "Build Your Own Website", primarily because it promised to be "A Comic Guide to HTML, CSS and WordPress", and that indeed it is.

I should probably mention that by "a comic guide", it does not mean in the funny sense (though some of it is), but in the illustrated, graphic novel sense. For those familiar with NoStarch Press and their "The Manga Guide to..." series of books, Nate Cooper's writing and Kim Gee's artwork fits very well in that space. What's more, "Build Your Own Website" follows the same template that "The Manga Guide to..." books do, in that each section starts with an illustrated graphic novel treatment of topics, and then follows on with a more in depth prose treatment of each area.

So what's in store for the reader who wants to start on a mission to make their own site from scratch?

Chapter 1 starts with our protagonist Kim looking forward to her first web design class, and shows that inspired and excited first timer's desire to get in and do something. It's followed by an explanation of the tools needed to be downloaded and do the work necessary to complete the examples in the book. All of the exercises and examples can be done for free, all you need is a web browser or two, a text editor, an ftp client (the book recommends FileZilla; it's the one I use as well) and you can get a free WordPress account at http://www.wordpress.com.


Chapter 2 talks about The Trouble with HTML, and how Kim and her dog Tofu meet up with the Web Guru, who introduces them to the basics of HTML, paths and naming conventions, loading pictures and following links, the hierarchy of files and directories that make up a basic web site, and a dragon called "404". The second section goes into details about all of these including explaining about document structure, HEAD and BODY tags, the items that go in each, embedding images, and a basic breakdown of the most common HTML tags.


Chapter 3 shows us how Kim Makes Things Look Great with CSS. Well, Glinda, the Good Witch of CSS helps Kim do that (graphic novel for kids, gang. Work with me, here ;) ). Glinda shows Kim the basics of CSS including classes and IDs, inline styles and external stylesheets that can be referenced along with inline styles, effectively creating a "cascade of styles" (CSS == "Cascading Style Sheets"). The chapter also discusses using div's for creating separate sections and blocks that CSS can be applied to, and ends with commonly used CSS properties.


Chapter 4 is where Kim Arrives in WordPress City, and where the examples focus on, of course, WordPress as a composition platform. Kim gets introduced to what WordPress is, which is a Content Management System (CMS), and the conventions of creating both blogs and websites. Kim is introduced to the Dashboard, creating posts, using the Visual editor, structuring her site, using Categories and Tags, using the Media Library to store media items, and the overall Theme to be used for the site. Each of these is covered in greater detail with examples in the second prose part.


Chapter 5 takes us to Customizing WordPress, and the myriad options that Kim can use to make her site look the way she wants it to. She is introduced to the Appearance panel, the difference between free and premium Themes, plugins such as Buy buttons or sharing posts on social media, Widgets that perform special functions that can be replicated for sections or each page, changing the navigation options to get to your pages quickly, and how each of the elements of WordPress are built on HTML and CSS (as well as things like JavaScript, PHP, Ruby, etc.).


Chapter 6 brings us to The Big Launch, where Kim and Tofu navigate the realities of hosting the site and how to set up hosting so that they can display their finished site to the world. There's lots of options, and most cost some money, but not very much (plans ranging from $5-$10 a month are readily available). Registering a domain is covered, and many sites have an option to install WordPress and use it there.


Bottom Line:
"Build Your Own Website" starts with some basic HTML and CSS, and then spends the bulk of the second half of the book introducing you, the user, to WordPress. For those looking to see the nuts and bolts of making a web site from scratch, including making the navigation elements, more involved interactions, and other esoteric features of web sites outside of the CMS system that WordPress provides, you will be disappointed. Having said that, if the goal is to get a site up and running and using a well designed and quick to use interface, WordPress is a pretty good system, with lots of flexibility and ways to make the basic formatting of a site nearly automatic. Younger web development acolytes can get in and feel what it's like to design and manage a site. To that end, "Build Your Own Website" does a very good job, and does it in an entertaining and engaging manner.

I would recommend this as a good companion book with "Lauren Ipsum", so as to give some high level computer science interaction. Both books also show that young programmers can get in, see what is happening, and become curious as to what comes next. From there, focusing on books that deal with JavaScript or frameworks for setting up sites will be less of a jump, because we can look back at WordPress and its CMS and say "oh yeah, that looks familiar". "Build Your Own Website" sets up a nice foundation, and makes a good jumping off point for those further explorations.

Book Review: Design Accessible Web Sites

This is a bit of a retro review, but since I’m in the process of putting together a talk about the design and testing aspects of sites as relates to accessibility, this came recommended as a good starting point.

Many books that talk about designing for accessibility tell you a lot of the what and the way around accessible design, but don’t put much emphasis on the how. Jeremy Sydik’s book “Design Accessible Web Sites: Thirty-six Keys to Creating Content for All Audiences and Platforms" does an admirable job on explaining the "how" of accessible design.

This book was originally published in 2007, so the technical underpinnings of the web have certainly changed a bit, but the overall message of “Design Accessible Web Sites” is still very relevant and still very usable. In the current rush for the latest and greatest, with frameworks abounding to handle just about every conceivable interaction, there comes a need for programmers and site designers to step back and consider if they are making it possible for the most people to use the sites and access the content they provide.

The core of the book revolves around what Sydik calls the Ten Principles for Web Accessibility:

1. Avoid making assumptions about the the physical, mental, and sensory abilities of your users whenever possible.
2. Your users’ technologies are capable of sending and receiving text. That’s about all you’ll ever be able to assume.
3. Users’ time and technology belong to them, not to us. You should never take control of either without a really good reason.
4. Provide good text alternatives for any non-text content.
5. Use widely available technologies to reach your audience.
6. Use clear language to communicate your message.
7. Make your sites usable, searchable, and navigable.
8. Design your content for semantic meaning and maintain separation between content and presentation.
9. Progressively enhance your basic content by adding extra features. Allow it to degrade gracefully for users who can’t or don’t wish to use them.
10. As you encounter new web technologies, apply these same principles when making them accessible.

Part 1 lays out the case for why accessibility is important (it’s good business, it;s the right thing to do, it’s the law in many places, and accessible sites are more usable for everyone). This section also steps through a variety of disabilities, some of which we automatically associate with Accessibility (visual, auditory and mobility impairments, as well as a variety of cognitive impairments and those who deal with a combination of the previous issues, specifically due to the results of aging). It also introduces the first eight “keys” of preparing for making an accessible site, including planning, making multiple access paths, avoiding the WET trap (WET stands for “Write Everything Twice”), and to set a solid foundation of accessibility testing, which really does require sapient skills to do. Automation can tell you if a tag is there or not, but it cannot tell you if a user experience for a disabled user is comparable to one for a normative user.

Part 2 focuses on building a solid structure for your pages, with thirteen additional keys to help you design your pages with accessibility in mind, such as keeping the site design simple, removing style from structure as much as possible, using links effectively, designing interfaces that emphasize the selecting of elements and actions rather than drag and drop movement, breaking away from tables and creating forms that are easy to follow and intact with without losing their interactivity or power.

Part 3 focuses on the visual aspects of the web, specifically how we deal with photographs and video clips. the nine keys in this section focus on selecting colors that contrast and don’t blend together, utilizing alt tags as more than just a place holder for generic text, and encouraging a design that can describe itself and allow the user to “see” the whole picture, or “hear” the whole story, even if those options are not on the table.

Part 4 looks at some additional aspects of accessibility and rounds out the last six of the thirty-six keys with how to work with documents that are not traditional for the web, options for dealing with PDF files, scripted output, as well as with Flash and Java apps.

Part 5 is a reference to a variety of web accessibility guidelines including WCAG, US Section 508, and examples from around the world, including Australia, Canada, European Union, Japan, United Kingdom, United Nations, etc.

Bottom Line:

To design sites that are accessible, we have to think differently, but the differences need not be radical. Also, accessible design need not be boring design. There are plenty of techniques and approaches to use that will help make sites easier to interact with for a broad population, and for those willing to embrace this approach, having the capability of designing sites that are accessible could be a differentiator for you as compared to other designers, programmers and testers.  As the tenth principle says, "As you encounter new web technologies, apply these same principles when making them accessible.” Technology moves on, but the advice and methodology is still sound, making ‘Design Accessible Web Sites” an evergreen title to consider for years to come.

TECHNICAL TESTER FRIDAY - Getting UnGraphical with lynx and grep

Use lynx --dump to retrieve the contents of your Web site. Just hardcode all the page URLs. Redirect all the content to flat files, then use grep to look for patterns in your content. Start by looking for mistakes you commonly make. Save your greps in a file.

Wow, now this brings back some memories :). 

I first loaded up a lynx browser back in 1993, and this was my introduction to what the non-graphical World Wide Web looked like. Truth be told, I fairly quickly abandoned lynx as an everyday platform when both NCSA Mosaic and the first version of Netscape came out, but there is indeed a value to using lynx. It’s a nice tool to add to accessibility tests, so that you can see what your super pretty graphical page looks to those who don’t have that option. For those curious... it looks like this (well, mine looks like this):

Yep, that's what the Web looked like in 1993. Cool, huh?

lynx —dump does exactly what it sounds like.

Here’s an example from my own little site project:

lynx —dump http://127.0.0.1/web/orchestra/index.php

This prints the following to the screen:

Adding a redirect tag (‘>’) puts it in a file for us. repeat a bunch of times, and you can pull down details on every page in your site.

OK, cool, that’s interesting, but what does that do for us? It allows us to go through and pull out data that we’d want to analyze. Granted, the site as it exists right now isn’t all that spectacular, but it does give us a basis for how we can construct some simple greps. 

For those not familiar with this tool, "grep" is an old UNIX standby. The term comes from the syntax of the “ed” editor, and the command that was used was g/re/p (or “globally search for a regular expression and print it to stdout”).  Those of you with Windows machines can download Grep for Windows at http://gnuwin32.sourceforge.net/packages/grep.htm, or you can find a variety of fun an interesting versions. For me, since my system is in a virtual environment, I'm just going to save the files to my shared folder space and play with grep on my Mac :).

The main benefit to using grep is to look for things that show up in your pages that you may find interesting, or things that might be errors. Searching for basic strings in file names can show a lot of interesting details in the content of the pages. As a quick set of examples that we can do using grep, I recommend poking around on this page for 15 command examples in ways you can use grep to get interesting data.

Once you find a few greps that you find useful, it's a good idea to save those in a file so that you can run them over and over again as you add content to the site and get more information to mine from your site.  

This is meant to be a really basic first step in getting into the details of what your pages show and help get you away from using the browser as a main interaction source. Yes, there's a lot that can be done just with the files and the content that is in them. How you choose to look at them and what interesting details they show will be my focus for next week.

TECHNICAL TESTER FRIDAY: And After Awhile... You Can Work on Points for Style

Last week was a bit of a whirlwind. I took my son out for a quarter cross country trip to check out a University he may be going to. Needless to say, that took a few days out of my reality. Between being in airplanes, rental cars and dealing with less than stellar rural WiFi in spots, let's just say I'm a week behind where I should be. On the bright side, I do have some stuff to show, and a little bit of extending on the theme of PHP being a site driver.

One of the interesting paradigms that shifted for me with some of the abilities that PHP provides is that I now look at pages differently. I used to use simple tools like Sea Monkey or some other cheap WSIWIG editing tool, chopping out anything that would be overhead, and making some simple frame-ups that I could use to quickly drop in text, make changes, etc. It was intensely manual, but hey, I was rolling my own, so I was OK with that.

Then PHP came along and messed up everything, and bless it for doing exactly that :).

The last time we were together I started looking at ways that I could clean up the pages, put some basic style ideas together, and make a site that would be less of a pain to maintain. Did I succeed? In some ways yes, but in others, I’ve traded one series of challenges for another. Some things are much easier with PHP, and some things allow you a wide latitude to do things that are hard to track down later. The key point, though, is that we can emphasize interactivity and automation for the pages rather than brute force updating and modifications. 

I've taken some time and cleared the game on the HTML and CSS module that Codecademy offers, and I have to say it's actually a pretty good synopsis. the HTML is pretty basic, but it made for a nice layering to teach the ideas behind CSS and where to use them. There's a lot of options that allow for fine motor control of the pages, but I think the best is the rapid templating that it can give to a site designer.

Here's my current index.php file, which is what I now use as my base template for all pages of the proposed "Youth Orchestra" site:

Yep, that's it. Pretty much every page in the site now has this as its basic template. What does the main site look like now?

Yeah, I know, I've moved from 1995 to about 2002 ;). Again, this was so that I could focus on using a few key attributes and not drowning in them. The main idea that I wanted to focus on was how to create a fundamental "box model" that would be easy to use as a base for all of the pages, regardless of what they were to display. 

Each of the main sections of the page are spelled out as div's, each with a unique class or ID. We have the header, we have a nav bar, we have a left side bar, a right main content area and a footer at the bottom. Each of those areas is defined (more or less) by a placement of the individual div elements. 

The style page is not terribly expansive, but it gives a little better view than it did before. also, there's a whole bunch of things that we can still do with these pages, and I am not even close to done. Added to that, there's still no JavaScript in any of these pages. I'm aiming to boost that net week, when I start getting more aggressive with forms and media displays.

Here's a look at the CSS file as it currently exists:

Again, these are pretty basic commands. Not a lot of fancy footwork is going on in here just yet, but that's a good thing. My goal is to try to look to see where I can decouple dense HTML and atomize the items, perhaps in small PHP pages,  or perhaps make it purely database driven (or as much as possible). 

Also, while I am starting to use HTML5 conventions for the base HTML structure, I'm using the standard div structure and giving each dive a unique name or attributes, so that I can, again, simplify what each page needs and what I need to maintain. At the moment, the separate PHP files are currently echo statements with raw HTML listing. It's a step up on the maintainability scale, but part of me hears Paul Stanley from his "100,000 Years" banter on KISS Alive saying "Now come on! I KNOW you can do better than that!!" On the bright side, it gives me something to look forward to and tweak a bit more.

For those that want to follow the ideas from this session, my recommendation is to work through the examples on Codecademy, practice all of the examples, and as you perform each step, grab a snippet here and there and use the ideas to build your css file. try to arrange the items as much as possible from most expansive to the most localized, and if possible, try to keep elements that have an impact or relation on each other close together. 

At some point, if the site gets sufficiently complex, that will become more difficult, but seeing each of the CSS elements, classes, pseudo classes and option in plat, it really becomes easier to separate the structure from the style points. I still have a fair amount of decoupling to do, specifically the use of tables, and I also need to look at more granular positioning and locking of elements in place (almost there, but there's still a little fudge factor going on with the divs). On the bright side, we're moving forward and making progress, and that's what matters :).

TECHNICAL TESTER FRIDAY: A Bare Bones PHP Site and a Foundation for Further Work

Last week was a comedy of errors. Between trying to focus on getting a live site to behave itself, having numerous back and forth support calls and explanations of "oh, we're sorry, but you'll need to upgrade to our new hosting service to get those features", I finally said "the heck with this" and built a brand new virtual machine (Windows 7) using EasyPHP (just because I saw some friends mention it and I figured "Hmmm, why not?").

I'm going to go on the record and say, for this first part of the process, if you want to have the quickest, start to finish, least amount of resistance approach to working with PHP to build a basic web site, a VM with EasyPHP may very well fit the bill nicely. With it you get the latest PHP, MySQL, Apache Server and a host of other nice features to help you navigate and manage what you need to do. All of which will help give you spare cycles to actually build a site using PHP.

The first few weeks have been looking at PHP and understanding where I can use it, and why I might want to. At the absolute simplest level, it's a great way to template base pages with pieces that you know you will use over and over again. Headers and footers? Not likely to change very much, so why copy and paste a bunch of code? Make a base php script that echo's out what you want to have appear, and have that item appear in the location you want it to on each page. Change the script, and it instantly changes everywhere it's being called. Seems really obvious after you do it, but there's that moment where you realize "Wait, are you serious? It CAN'T be THAT simple!" Actually, yes it can be!

Another nice thing that you can do with PHP is make your database connection strings, as well as your common SQL commands, and store them in a script. By inclusion, you don't have to go and edit a bunch of scripts to issue the same commands over and over, or change statements in a bunch of files. This is where that whole "red, green, refactor" aspect of Test Driven Development can be felt, and wow, it's kinda' cool.

Another thing that I like about EasyPHP, as opposed to working with the live site that I was playing with, is that the debugging process is much quicker. On my live site, I would get errors and have no clue what was happening. I'd have to comb through several log files to figure out what was going on. Here, the system is set up to put all debug messages to your response pages. May seem a bit obtrusive, but really, it's hugely helpful. 

Also, programmers, I've always known this, but the past couple of weeks have reminded me of it again. Debugging programs can be a real challenge, and you can go through what look to be identical programs, line for line, and you cannot for the life of you figure out what the heck is wrong. I had one of those situations this week where I kept looking at why I couldn't update my database with a submission from a page, and it took me 45 minutes to realize I'd posted a comment with a contraction. Perfectly normal thing for someone to do, and yes, the answer is to make a substitution and escape character to handle the single quote, but that's where I ended up losing 45 minutes of my life wondering "why won't this thing work?!!" This emphasizes why programmers are often the worst testers when it comes to their own code. It's the same reason that writers/bloggers are often the worst proofreaders of their own posts (and oh, am I ever guilty of THAT). 

So have you had enough of me prattling on about all this? Where's my site? What did I put together? OK, here ya' go :).

Please, contain your excitement (LOL!).

Yes, I know what a lot of you are thinking. "Seriously? You spent three weeks and this is the best you could come up with?" Correction. I spent three weeks trying to make sense out of what PHP can do, reading up on it, practicing it and playing around with it, while I spent a week getting a MySQL instance to try to behave itself, and then gave up and created an environment from scratch (EasyPHP, from start to finish, install to fully up and running, a total of fifteen minutes. I kid you not).

OK, but the results look a little... well... 1995!

Right!!!

This set of pages is almost 100% pure HTML and PHP. I have exactly two CSS statements. One defines the size of the Submit button in two forms. The other makes for a sans serif font base for the whole site. That's it. Why? Because the prettified version, using CSS, HTML5 and JavaScript, is the next part of the challenge (consider it Noah's "Chapter 2"). 

I've got to give him credit, Noah Sussman is smart with this first step. CSS and JavaScript are big topics, they can take users into lots of different directions. I wondered why Noah wanted us to just focus on PHP for the first part of this project. I think it's because, with that constraint, we can actually consider just how much stuff we can do using only PHP. 

- Want to have a particular part of your site appear at a particular time or set of days? 

- Want to have a number of simple components, like your header and footer, be 100% predictable? 

- Want to have a single place to put SQL variables and a collection of commonly used queries, and only have to change the function calls and parameters based on input? 

In fact, with enough forward thinking, almost all of a site's content could be made up of just include and require statements. 

Again, these are simple steps, nothing Earth-shattering going on here, but they show that, with a little bit of work, and maybe stashing of some syntax examples to use later, you can get a feel for what to do to make a site that is mostly using PHP scripts for content creation.

So what can be gleaned from the first part of this series?

- Technical testers need to realize that programming, any kind of programming, really does take a different mind set and paradigm than manual or exploratory testing does. A tester looks at a finished Lego model and says "how can I see the structure?" A programmer takes a bunch of pieces and thinks "how can I take all of these pieces and put together the finished Lego model?" Programming requires an ability to string small pieces together, and the patience to "accrete" something from very small components into a larger whole. Testers tend to take items in their larger whole and break them apart to get to their individual components and find the relationships. I've intuitively known that, but these past few weeks have made that a lot more obvious.

- PHP alone gives a site programmer some neat tools to gather up ideas and make little bits of reusable code that can appear in lots of places, or create contexts in which the code can be used in a variety of ways. The syntax and the mechanics are similar to many other languages, and getting the feel for the language and what it can do can be done in a fairly short order just by working through the examples at Codecademy. Syntax alone, though, doesn't do much for you. You need to start looking at your pages and start thinking "hmmm, could I use PHP there?" As I've found out, the answer is, well, yeah, just about anyplace, and for a whole variety of things.

- PHP does give you the ability to automate some controls, send and receive information from a database, display data on the page, and do a number of cool manipulations. Without CSS or other "sweeteners", though, it looks jut like old school raw HTML of yesteryear. We could embed CSS statements inside of PHP, but that gets ugly really quickly, and then it makes it murder to change later. PHP is good for quite a few things, but style isn't one of them. Fortunately, I'll get the chance to play with style in the upcoming week.

Oh, one other mention, and I'm going to do a full review on it in the next couple of days. While the point of these posts is to highlight things that are free, open source or easily obtainable through a web search, I do want to mention that I found the "Head First PHP & MySQL" book to be very valuable for this part of the process. The individual concepts for things like configuring Apache, using MySQL and getting syntax for PHP can all be handled with a Google search, but the Head First book gives a variety of little projects to do, all of which help to get the programmer into the mode of coding up working examples, including mistakes that can be fixed, designs that can be refactored, and projects that can be easily ported to other uses. I have some other comments, both pros and cons, but you'll just have to wait for my more complete review ;).

The wheels are now on the car, I have a little bit of gas in the tank, the vehicle starts and can be driven, at least a little. Now let's see if we can clean it up a bit and make it a bit more presentable. Hope you'll join me as I continue the journey :). 

Book Review: A Web For Everyone

When I started working at Socialtext, I came in right at a time when we were working on a large Accessibility project. For those not familiar with the term Accessibility, it’s the variety of standards, tools, and devices that collectively allow for individuals with disabilities to get access to the information, either on their systems or on the web, and interact with it as seamlessly as everyday users that do not have disabilities. 

There are several standards that can be referenced and used as starting points for understanding accessibility, and a variety of tools, both free and commercial, exist to help the programmer and tester address accessibility issues, create fixes, and test them to see if they work as intended. Over the past year, Accessibility has become a focal point of my testing practice, one I didn’t spend much time thinking about or doing prior to working here.

While it’s important to understand accessibility, it would be even better if more people  were to give thought to accessibility and testing for accessibility in their design decisions, and early in the process make the case that Accessibility to all users (or as many as possible) is an important part of our mission as product owner, creators, designers and testers. Sarah Horton and Whitney Quesenbery approach this challenge and this mission with their book “A Web For Everyone”. More than just ways to code and test for accessibility, this book attempts to help anyone who creates software applications to develop the understanding and the empathy necessary to make design decisions that truly help to make "A Web for Everyone" possible.

So how do Horton and Quesenbery score on this front?

Chapter 1 lays out the case for why we all should consider creating A Web for Everyone, and using the  “Principles of Inclusive Design” (POUR) at the outset. Inclusive design can be seen as the cross section of good design, usability and accessibility. The Web Content Accessibility Guidelines (WCAG) 2.0 standard is introduced, which encompasses various accessibility standards in use in the U.S., the U.K., the European Union, etc. Pour uses seven principles for helping design products that work for the widest range of abilities. Equitable, Flexible, Simple, Intuitive, Perceptible, Tolerant and Considerate of Space and Effort make up the core of POUR. This chapter also focuses on Design Thinking, which emphasizes understanding the human needs first, rather than letting the technology dictate the scope or direction. Combining WCAG, POUR, universal design, and design thinking, starting with the user experience, we can make great strides in designing sites and applications that allow for the greatest possibility of use by a broad variety of users and ability levels.

Chapter 2  introduces us to the idea of People First Design by introducing us to eight different people. To those unfamiliar with the idea of “personas”, this is a great introduction, and a really nice modeling of the idea. Rather than make eight abstract personas, the book outlines eight people in quite specific detail; their physical and cognitive abilities, their skill with technology and understanding/knowledge, and attitudes (motivation, emotions & determination) are fleshed out so that we can relate to them, as well as their unique challenges and abilities/disabilities. By having so much detail, we can empathize with them as though we actually know them. Personal interjection here; even with this level of detail, personas are, by necessity, incomplete. They are stand-in’s for real people. While we will have to “fill in the blanks” for a fair number of things, the more complete a persona we can make and identify with, the more likely we will be able to consider their interaction and design for them to be effective.

Chapter 3  sets the stage for the idea of “Clear Purpose”. Clear Purpose starts with understanding our audience, putting “Accessibility First” to ensure that the broadest group of people can use the product effectively. Emphasis on universal design and equivalent use are more desirable than accommodation, since accommodation usually makes for a less fulfilling experience.

Chapter 4 focuses on Solid Structure. An emphasis is placed on the various markup and presentation options including the options associated with HTML, HTML5 and WAI-ARIA, separating the content from the presentation (yes, CSS is useful for accessibility as well as for eye candy) and optimizing content to be organized in a way that screen readers and assistive technologies can get to the the most important content first. Most important, sites with well defined structure help to remove barriers, and give users confidence they can find what they need when they use a site or an application. 

Chapter 5  covers Easy Interaction. By focusing ion making interactions easy for those with  disabilities, we go a long way in developing a product that is easier to interact with for everyone.  Focusing on keyboard interactions, having codes in both HTML and CSS that leverage assistive technologies to provide more details or outline areas where the keyboard has focus, or to speak to the user where the keyboard focus currently is. Easy interaction enables users to control the interface, with large enough controls. It avoids taking unexpected actions for users that they can do on their own. Easy interaction also includes both preventing and handling errors in an accessible way.

Chapter 6 is all about orientation and navigation, or as the book puts it, “Helpful Wayfinding”. This consists of being consistent with design elements, mapping items similarly on pages so that the look and feel remains consistent, differentiating where it really makes sense to differentiate, and include information as to where a user actually was in the site (think of the bread crumb trail we often take for granted). ARIA roles work with HTML and HTML5 tags to help define where on the page the user is to that assistive technology can reference those rage and provide meaningful alerts and signposts. It also gives some good suggestions as to how to pattern links and navigation items, such as using action words as links, presenting links in an obvious and consistent way, including images as clickable elements, keeping the navigation process simple, and resisting the temptation to bury content in layers of submenus.

Chapter 7 focuses on Clean Presentation, or placing a focus on the visual layout, images and fonts for easy perception. To get the best effect from this, though, Clean Presentation looks to take into consideration a variety of visual disabilities, as well as allowing users the ability to customize the look and feel, using native browser options or physical controls in the site or app itself (think of the font enlarging/shrinking of a Kindle eBook as an example). Stylesheets can help considerably in this regard, and can allows the visuals to me modified both at the user preference level and at the device level (laptop, vs. tablet. vs. phone). Making a contrast between the text and background, font size, style, weight, and spacing, as well as the contrast for images can also help make a site more usable.

Chapter 8 gets to the heart of the matter regarding “Plain Language” Not to be confused with “summing down” content, but writing to the intended audience with words and terms they will understand. Plain language also helps drive content presentation. Clear headings, columns to break up text, small paragraphs, bullet points and use of bolding, italics and links. In general, make it a point to read your site regularly, and incorporate your personals to see what they would think of your presentation.

Chapter 9 covers Accessible Media. Much of what we post requires visual cues. Images and audio/video are the most obvious, and there are differing challenges depending on the individual and the disability. For sighted users, image rich sites can be little more that large blank canvases with a  few words here and there. Audio files cannot easily be consumed by those who cannot hear. This is where  aspects like alt tags for image, closed captioning for video files, transcripts for audio files, and other ways to describe the content on the page will goa long way towards letting more people get involved with the content. 

Chapter 10 brings us to Universal Usability, or put in a different way, a focus on a great user experience for all can go a long way towards helping incorporate many accessibility ideas for everyone. Technology should not have to be fought with to get a job done, or to accomplish a goal. Well designed sites and apps anticipate user interaction, and help guide them to their completion, without requiring a lot of redirection or memorizing of options to get a task completed. A popular phrase is “Don’t make me think!” the site or app should allow the user to focus on their goal, not trying to figure out how the site or app needs to have them achieve it. 

Chapter 11, In Practice, looks to unify the concepts in the book into a holistic approach.  More than just using the techniques described, the organization as a whole needs to buy into the value of accessibility as a lifestyle and a core business goal. Start by evaluating your current site and seeing where you re doing well and where changes would be valuable. Determine what training, skills, people power and infrastructure will help you get from A to B. Also, while personas are a great heuristic, they do not take the place of flesh and blood people dealing with the various disabilities we want to help make our software accessible to. Look to interact with and develop relationships with real people who can give a much clearer understanding of the challenges, so that you can come up with better solutions.

Chapter 12 considers The Future, and what A Web for Everyone might look like. Overall goals include a web that is ubiquitous, where accessibility is part of design from the ground up. Another goal is flexibility as a first principle of design. Our interaction should be invisible, or at least stay out of our way as much as possible. Methods in which we will get to that place will involve being more inclusive and diverse in our understanding of who uses our products, and how they use them. We’ll need to make accessibility part of the way we think, not as an afterthought after we’ve done everything else.

The book ends with three appendices. Appendix A is a brief listing of all the principled discussed in each chapter, and would make for an excellent starting point for any story workshop or test design session. This is a great set of “What if?” questions for software testers. Appendix B is a summary of the WCAG 2.0 standard and how the various sections map to the chapters of the book. IF you want to get into the nitty-gritty details of the spec, or get access to other links and supporting documentation, that’s all here. Appendix C gives a lengthy list of additional reading (book, links, etc.) about the topics covered in the book. If you want to know more about any specific area or heading, check here.

Bottom Line:

"A Web For Everyone" gives a lot of attention to the the personas and real world examples of accessible design, which are interspersed through all of the chapters. We see their plights, and we empathize with them.  These persona examples are humanizing and very helpful. They help us see the what and the why of accessibility. We see many interesting design ideas shared, but we get only a few examples of the how. Implementation is discussed, but only a few ideas are fleshed out beyond the basic prose. This is not necessarily a criticism, because A Web for Everyone does a really good job explaining the what’s and the why’s of accessibility design. High level design ideas and technology briefs are handled quite nicely. A variety of coding examples to show the ideas in actual practice, not so much. If you are looking for a guide to coding sites for accessibility with exercises and examples to create, this isn’t that book. If, however, you want to get inspired to make, test or promote software that can be used and usable by a broader variety of people, this book does an admirable job.