Who did I do this for?

This was a project done for Fresh Tilled Soil's AUX program.

Specifically, the challenge was to take a static image of a form and code it in an accessible and semantic manner.

What problem did I solve?

The form required built in validation for both errors and credit cards. Furthermore, the form needed to follow the protocols of graceful degradation. So, it should continue to function even if a user doesn't have access to javascript.

Let's look at the form

static image of a sign up form

You can see the fully active gh-pages site of what I coded over here. It will open in a new tab.

The real challenge was atomically coding this form such that an entire team could use modularly to code consistent looking and feeling forms across an enterprise application.

How did I do it?

Following progressive enhancement, I built layers of markup wrapped around the basic content of the form.

Progressive enhancement is a strategy of web design that both centralizes and disperses an application's architecture. The content is condensed at the core of the system and styling is externalized in stylesheets and scripting.

The concept of graceful degradation has been around for a while. It is an engineering strategy related to fault tolerance and describes the ability of a system to continue operating regardless of the failure of some of its components.

Progressive enhancement is an element of graceful degradation. It involves planning the system to be insulated against fault by separating its architecture.

Let's look at the basic structure

static image of a sign up form

Here, we have the basic content of the form in place, semantically described by HTML in terms of fieldsets, legends and the inputs that correspond to those legends via id attributes.

If all else fails - if a CDN goes down, if a developer didn't have their coffee - a person should be able to interact with this form to do what they need to do.

What's next?

If a designer handed me the static PNG of the form and I handed them back the image above, I'd probably lose a my job. I'm off to a good start, because I have the framework for the content declared in the HTML and my next step is to apply CSS rules to describe its presentation.

Let's start applying styles

static image of a sign up form

Above, you can see the beginning phases of style declaration with CSS. Once the outline has been established, it's relatively easy to continue painting in the picture by styling the fieldsets, container divs for inputs, and other elements specified by the static image.

But, I'd be wrong to do that without first figuring out how these elements are supposed to act and if I really have the right objects in place.

What went wrong?

Occipital Structure Sensor Case Study

What is this supposed to be? What is this supposed to do?

The grayed out area that says, ".sample.com" looks like part of the overall input field. Is it? No. I can apply border-radius and can add curved borders to a div and make it look like that, but is it going to act the way it should? No.

If I simply curved those borders, what would happen when a person using a screen reader encountered it? Nothing useful to that person, unless I add a hidden span class to describe it. The W3C working draft states that divs, regardless of what role they are assigned, cannot have a label.

I can specify this as a disabled or a readonly input and, visually, get the same results in either case. The choice, though, affects how the cursor looks when a user hovers over this region and begets various types of default styles to override.

The argument for a read-only field is that the data may be POSTed to the server from the form. However, this is unlikely. It's more probable a server will generate the data and expose it to the front end through the disabled input.

If the field was declared a readonly by the HTML, a user could tab onto the field and be confused into thinking they should or could interact with the input.