Posted on

A Beginner’s Journey to Launching a Website

In September 2018, I was just a few months into my journey of learning web development. As I'm sure is the case with many new developers, it was a big task for me to learn not only the basic skills required, but also keeping current with the fast-moving industry. Just as I was getting to the level where it felt as though I could build a simple website, I started to realize that it was only the first step.

Opening up a few HTML pages stored locally on my laptop felt like a million miles away from being able to say to someone, "Hey, check out my website, live on the actual internet!"

But I did it! And the best part is that it wasn't as scary, difficult or expensive as it first felt like it'd be.

It all started with me sending Chris an email, which he used to write an awesome article explaining everything in plain English.

At this point, I didn't have a fully coded website — just an idea for a basic site that I was using to teach myself as I went along. I used the ongoing progress of my site as a push to learn how to get a live website quicker. But I'm sure you could do the whole thing with an HTML document that just says "Hello, world!"

I built my site using Gatsby, a static site generator powered by React. Building a website with these tools in a modular way felt really natural to me. The concept of reusable parts is something I’m familiar with in my career as a physical product designer and mechanical design engineer. It means that you can build in stages, like Lego, brick-by-brick, until you eventually have a life-sized castle you can invite your friends to visit!

This isn't a guide. It's my personal experience in the process of getting a website from my laptop to being live on the internet. Hopefully it'll give you some hope that it's possible and achievable, even by someone who has no formal training in web development and who has only been doing it for 12 months!

Domain registrars

Before I ever bought a domain, it seemed like a pretty serious thing to do. Owning a domain means being responsible for it. People will go to that address and eventually see content that you've put there.

I don’t know if everyone has the same experience, but I spent weeks deciding on a domain name before going for it. It almost became an obsession of mine for a while, searching online for acronym generators to try and be clever, spending hours on dictionary.com trying to find synonyms that were cool. In the end, I settled for my name and what I do: joshlong.design. I still smile a little when I see my name in the address bar.

Since reading Chris' article, I've actually bought two domains from two different providers: a .com and a .design. I realize that I went against Chris' advice of consolidating domain names at a single registrar, but I needed to shop around a bit to get a good deal on my .design domain. I only own two domain names — and one of them I don't actually have any plans for just yet — so keeping on top of where I bought them isn't a task. In fact, I don't remember the last time I needed to login and manage the domain I use on a daily basis!

Buying a domain name was as simple as any other online shopping transaction. Nothing really huge or scary about it. I bought my .com through Namecheap, and my .design through Google Domains, and the process was pretty similar for both. All they needed was my name, address and payment details. Pretty standard stuff!

I don't remember Google trying to sell me a load of extra packages. They seemed happy with me just buying a domain, though they did offer me free WHOIS protection which I snapped up because I didn’t want my contact details freely available for anyone who’s feeling nosey. However, as Chris warned might happen, the other registrar I went through tried really hard to sell me some extras like hosting, email, a VPN (whatever that is!) and SSL certificates.

Google Domains checkout is happy just to sell the domain name.
Namecheap tries to sell you all the additional services they offer before getting to the checkout.

I didn't go for any of those extras. I already had a hosting plan, and you can use an alias through Gmail to "fake" having a me@mycoolsite.com email address. I honestly have no idea why I'd need a VPN, and the hosting I was going to go for gave me a free SSL certificate through Let's Encrypt. So just the domain name, please!

Hosting

As Chris suggested it would be, choosing a host was a tad trickier than choosing and buying a domain name. But in the end, the web technology I used to build my site kind of guided me in a particular direction.

My site is built with Gatsby, which means it outputs straight-up static assets, basically as HTML and JavaScript files. That means that I didn't need a host that offered a server (in my most super smart authoritative voice), especially for WordPress with a MySQL database and Apache server, 6 cores @ 3.6 Ghz, 4GB RAM, 5TB bandwidth, 5 IP Addresses and 500GB SSD Storage, etc.

All that jargon goes straight over my head. All I wanted to do was upload my files to the internet and go to my domain to see them all compiled and shiny. Should be easy, right?

Well it turns out that it actually was that easy. As there's been so much hype around it recently, I thought I'd take a look at Netlify.

Netlify is recommended by Gatsby. They have really good documentation, and for my uses I felt as though I could comfortably stay within the free tier that they offer. In fact, at the moment I'm using 0.08% a month of the total bandwidth the free tier offers. Winning! Although maybe that means I’m not doing enough to get people to my site...

A quick aside about GitHub: I'm no expert at it and I don't really know any of the etiquette it entails. All I did was sign up, create a new repository and follow the instructions that they give you. After that, every time I made a change to my site, I used the buttons in my code editor (VS Code) to commit and push my changes. It works, but I have no idea if it's the correct or best practice way of doing it! I'm starting now, though, to understand how to use Git through the command line. I had no idea at all how to do it when I started, but I still muddled through it — and you can too!

Back to Netlify.

I signed up for an account (no credit card details required) and added a new site to Netlify by telling it about the GitHub repository where it was stored. When you’ve connected your repository, you can watch Netlify doing its thing deploying your site.

Part of the Netlify’s deploy process is that it shows your website going live in real time. That’s useful for debugging if something goes wrong, or just to watch and get excited like an impatient puppy waiting for a biscuit.
You also get a deploy summary to quickly see what files were uploaded during deployment.

After my site was deployed to the randomly generated URL Netlify gives you, I followed their instructions for adding a domain I had registered elsewhere. They make it so easy!

I assume the instructions will be different for different hosts, but basically, Netlify gave me some server addresses which I then had to go back to my domain registrar to enter them in. These addresses are referred to as nameservers, so look out for that word!

Netlify gives you your nameserver addresses and super easy to understand documentation to set them up with your domain registrar

Once I entered my Netlify nameservers into Google Domains, Google knew where to look to send people who type my domain name into their browser’s address bar. All I had to do after that was wait for some internet magics to happen in the background. That took around three hours for me but can take anywhere from 10 minutes to 24 hours from what I hear.

After that was done, I could type my shiny new domain name into the address bar and — just like that — I'm looking at my own site, hosted live on the internet!

Content Management Systems

The world of Content Management Systems (CMS) is vast, and confusing, but it can also be completely irrelevant to you if you want it to be. I felt so liberated when I realized you don't have to worry about it. It was one less thing in my list of things to do.

My Gatsby site posts and pages (my content) was just a directory of markdown files and my CMS was my text editor. Chris and Dave talked about the idea of this in a recent episode of ShopTalk Show.

My website content is managed right in my text editor, VS Code.

Because I wanted to have a standard structure for different types of posts and pages, I eventually started using NetlifyCMS which is an open-source CMS which can be included in your site real fast. (Chris also did a video recently about NetlifyCMS for his confer-reference site... see what I did there?!) Now I can create blog posts and drafts from anywhere in the world, straight from my website, as long as I have an internet connection!

The same content managed through NetlifyCMS, which offers a great UI and GitHub integration

Asset Hosting (CDNs)

A Content Delivery Network (CDN), as Chris explained in his article, is basically somewhere on the internet where you store the files you need for your website to run, HTML, CSS, images, etc. When your website needs them, it goes to the CDN and grabs the files for your site to use.

From what I've read, it's good practice to use a CDN, and because of the hosting decision I made, it's not something I have to worry about - it's included by Netlify as standard, for free!

Netlify has it's own CDN where all of the files for your website are stored. When someone goes to your website, Netlify goes to its CDN and grabs the files. It's amazingly quick, and makes your site feel so much smoother to navigate.

It's a long journey, but you can do it!

There was a point, before I set off on the journey of getting my website live, where I tried to convince myself that it's fine to just have local websites, as my career isn’t in web development. The reason for that was because the path felt like it would be difficult, long and expensive.

In fact, it was none of those things! You could get a website live on the internet for £0.99 (~$1.25 for you Americans) or less if you find a deal on a domain name. The domain name was my only expense because for the path I took for hosting, asset management and content management.

At a super basic level, the path looks like this..

Code > Buy Domain > Find/Buy Hosting > Update Nameservers > Upload Code > Live!

If you happen to use the same vendor to buy your domain name and your hosting, you can skip the nameserver step. (Netlify sells domains too!)

It's definitely possible for anyone to get their website live on the internet. There's a process that you need to follow, but if you take your time, it can be relatively straightforward. It's a really wonderful feeling, getting a thing you built in front of people, and it's honestly something that I thought I'd never be able to do. But it's certainly within everyone's reach!

Something I've come to really admire over this process (and thousands of Google searches) is the willingness of everyone in the web community to collaborate and help, accepting me and my questions as I tried to learn what I was doing. It's something that I wish was more common in my own industry.

I'd love to hear other people's experiences getting their first website live. What were your pitfalls and triumphs? Was it as scary as it first seemed?

The post A Beginner’s Journey to Launching a Website appeared first on CSS-Tricks.

Posted on

Why, How, and When to Use Semantic HTML and ARIA

Semantic HTML and Accessible Rich Internet Applications (ARIA) help create interfaces that work for everyone in the most performant, robust, and simple way possible. They add essential meaning to your content, which lets web browsers, search engines, screen readers, RSS readers, and ultimately users understand it.

And yet, many people still don’t use them. I wanted to know why, so I set up a Twitter poll. The most common reason people gave was a lack of awareness and understanding of the benefits of using semantic HTML and ARIA.

Let’s look over the benefits of using HTML and ARIA, why starting with semantic HTML is the way to go, and why ARIA ought to come in as a last resort.

Starting with raw text

The <body> element of an HTML document contains the main content a user sees on a page. If content is put inside the body without any additional elements, the browser has no way of differentiating between different types of content, like paragraphs and headings.

<body>
A Study of Butterflies

Butterflies are little bugs with cute wings.

Butterfly Habitats

Butterflies live in flower houses and hang out at dank coffeeshops.
</body>

If the browser can’t differentiate between pieces of content, then it can’t present that content to the user in a meaningful way. That means:

  • We can’t style the headings differently from paragraphs.
  • It’s harder for search engines to interpret the content, meaning it’s likely to rank poorly and be difficult for users to find.
  • Screen readers and other assistive technology can’t communicate it properly to the user.

Not to mention, it’s more than a bit awkward visually:

A screenshot of the HTML rendered on the front end, which displays as a single line of text.

Adding some structure with HTML

To provide some structure we could wrap the lines of text here in divs like this:

<div>A Study of Butterflies.</div>
<div>Butterflies are little bugs with cute wings.</div>
<div>Butterfly Habitats</div>
<div>Butterflies live in flower houses and hang out at dank coffeeshops.</div>

This is slightly better because each piece of content is displayed in the browser on its own line instead of one long unbroken line of text.

A screenshot of the HTML rendered on the front-end showing the content on four lines, one for each div.

But there’s still a distinct lack of meaning.

Which are headings and which are paragraphs? It’s hard to tell, and impossible for assistive technology to determine. That’s because the headings and paragraphs are wrapped in divs which are meaningless on their own. In this example, browsers, CSS, search engines and screen readers are still none the wiser.

Communicating meaning with styles

We could add styling to the divs because they can be targetted with CSS. This lets us improve the visual appearance to provide meaning, context, and hierarchy.

See the Pen
Non-Semantic HTML Demo by Geoff Graham (@geoffgraham)
on CodePen.

Here the CSS targets the first and third divs to apply heading styles. This isn't maintainable because another paragraph added afterward, for example, would get styled as a heading.

We could give each div a unique attribute such as an ID or class name, to give us more styling control, like this:

<div class="heading1">A Study of Butterflies</div>
<div class="paragraph">Butterflies are little bugs with cute wings.</div>
<div class="heading2">Butterfly Habitats</div>
<div class="paragraph">Butterflies live in flower houses and hang out at dank coffeeshops.</div>

I explain why you should use classes instead of IDs for styling in my online book, MaintainableCSS.

Now we can target the different elements with CSS like this:

.heading1 { /* styles here */ }
.paragraph { /* styles here */ }
.heading2 { /* styles here */ }

While this approach is a little better, it only communicates meaning for sighted users. It doesn't provide meaning to search engines, RSS readers and screen readers. In other words, it’s not semantic and not very accessible as a result.

Introducing semantic HTML

HTML provides many elements that are designed to give meaning to content, including elements for headings and paragraphs. So, instead of relying on divs with classes named by the developer, we can use predefined HTML elements instead.

<h1>A Study of Butterflies</h1>
<p>Butterflies are little bugs with cute wings.</p>
<h2>Butterfly Habitats</h2>
<p>Butterflies live in flower houses and hang out at dank coffeeshops.</p>

Much better! With semantic HTML like this, the content will inherit default styles from the browser (aka User Agent). We can even use other semantic HTML elements, like <b> which tells the browser to “bring to attention" by making text bold.

A screenshot of the HTML rendered on the front end showing the content with a clearer hierarchy of a Heading 1, paragraph, Heading 2 and paragraph, thanks to semantic HTML.

Crucially, using semantic HTML also means:

  • We can use CSS to add our own styling.
  • Search engines can index the content so that it ranks well enough that users can find it.
  • RSS readers can parse and style the elements appropriately.
  • Screen readers and other assistive technologies can communicate elements properly to the user.

While it’s not massively important in these short examples, the code is also more concise which makes a big difference when considering an entire site.

Semantic HTML is standards-based and stable. This means any HTML processor in the future will be able to understand it and present it correctly to users. It will also help subsequent code authors if they need to make changes.

Additional benefits of semantic HTML

In addition to the benefits we’ve covered so far, some browsers add useful enhancements to semantic HTML for free.

For example, using the HTML telephone input (<input type="tel">) will give users a telephone-specific keypad on some mobile browsers.

Identifying a form input as a telephone field will produce a telephone-specific keypad in iOS. Careful though, because it’s just for telephone numbers and not meant for any number, like credit cards.

Other browsers give users the option to switch to a simplified view of the page, like Safari’s Reader Mode. Without semantic HTML, Reader Mode would produce something much like the one-line string of text we started with. But, by using semantic HTML, we get a clean reading experience without any additional styling on our end:

The About page on my personal website viewed with Safari’s Reader Mode, comparing unsemantic HTML (left) with semantic HTML (right).

You can read more about this in Mandy Michael’s article on building websites for Safari Reader Mode and other reading apps.

When ARIA makes things better

Like semantic HTML, ARIA is a W3 standard that helps make interfaces more accessible to people who use screen readers and other assistive technologies to consume content.

Error messages are a good example. If a user leaves a required form field blank, the HTML for the error might look like this:

<label for="first-name">First name</label>
<span>Enter your first name</span> 
<input type="text" name="first-name" id="first-name">

A sighted user will be able to see the error above the field. But when a screen reader focuses on the input, the error won’t be announced because the error message isn’t linked to the input.

ARIA can be used to associate the error with the input like this:

<label for="first-name">First name</label>
<span id="first-name-error">Enter your first name</span>
<input type="text" name="first-name" id="first-name" aria-describedby="first-name-error">

Now the error message is announced when the input is in focus.

Using ARIA and JavaScript together

ARIA is most useful when JavaScript is involved. JavaScript is usually required to create more complex and dynamic interactions like hiding, showing and changing elements without a page refresh. Think toggle menus, accordions, tabs, auto-completes, sortable tables, loading content and saving, sending or getting data. Enhancing interfaces like this often breaks the experience for screen reader users.

Take a button that, when selected, reveals other content. In the original state, a sighted user will initially see a button and no content and, when the button is clicked, the content appears.

A visually-impaired user with a screen reader, however, usually relies on spoken cues as they navigate through an interface. But when a screen reader focuses on the button, there’s nothing to tell it if the content is currently in view and needs to be read.

The aria-expanded attribute can be added to the button, and JavaScript can toggle its value between true (content is showing) and false (content is hidden). This helps to meet Inclusive Design Principle #1, provide a comparable experience to screen reader users.

<button aria-expanded="false">Toggle content</button>
<div hidden>Some content</div>

Try to avoid using ARIA to fix unsemantic HTML

ARIA attributes can be used to make unsemantic HTML more accessible to screen reader users. For example, a developer who is struggling to style a native checkbox across multiple browsers might decide to use a div and some JavaScript to emulate one.

We can add a role of checkbox to make the div identity itself as a checkbox to screen reader users:

<div role="checkbox"></div>

We must also use the aria-checked attribute to indicate whether or not the checkbox is checked like this:

<div role="checkbox" aria-checked="false"></div>

But, this still isn’t enough to make it behave like a checkbox because divs aren’t focusable by keyboards like <input type="checkbox"> is. We could make them focusable by adding tabindex="0":

<div role="checkbox" aria-checked="false" tabindex="0"></div>

But even then, a real checkbox, when submitted as part of a form, will send its value. Because this isn’t an actual a checkbox, it won’t submit its value without using JavaScript.

And if that weren’t enough already, users can check or un-check a real checkbox by pressing the Space key. And, the form the checkbox belongs to can be submitted by pressing Enter when the checkbox is in focus. But the div-version checkbox won’t do this without even more JavaScript.

Not only is this more work and more code, but the approach only actually works for people who use technology that understands these particular ARIA attributes. That’s a lot of effort, a lot of code and a lot of problems that we can avoid entirely if we just use semantic HTML:

<input type="checkbox">

There’s no denying that ARIA is useful in certain situations, but starting with semantic, accessible HTML where possible is infinitely simpler and more reliable. That’s why the first rule of ARIA is not to use it.

Conclusion

Inclusive design is about providing the best possible experience to the broadest range of users. Semantic HTML helps technologies and therefore users understand content on the web. Enhancements offered by some browsers and devices mean that users get an even better experience baked in.

And when semantic HTML alone is not enough on its own, ARIA can provide more context for users of assistive technologies, but use it with caution. It's not a hard and fast cure for unsemantic markup and can become complicated, as we saw in that last example.

In short, do the hard work to make things inclusive. It’s a win for you and a win for the web.

The post Why, How, and When to Use Semantic HTML and ARIA appeared first on CSS-Tricks.