Skip to content
Coding Journal

My Learning Blog

This blog is for me to keep track of entries on subjects I’ve touched upon. This blog will continue to grow as I study. The blog was officially started June 2021, and does not include subjects I have studied beforehand.
Accessibility for Web Development

Accessibility for web development is making web content available for people with all types of disabilities, either permanent, temporary or situational disabilities.
Permanent disabilities can be issues like having only one arm, being blind or deaf.
Temporary disabilities can be situations like having a broken arm, being cataract (temporarily blind) or having an ear infection.
Situational disabilities can be situations to you or your environment like having one arm less because you’re a parent with a newborn, being distracted by something visually, or being in a loud noisy crowd.

Benefits of having an accessible design can be the following:
Your solution will have better overall usability.
You’ll reach a larger audience (Approx 15% of the world have a sort of disability).
SEO ranks you higher if your site is accessible.

A fun list of companies whom have been sued due to their websites or apps did not meet the American WCAG (Web Content Accessibility Guidelines) standards and lost:
Harvard University
Fox News

Which is yet another reason to prioritize developing accessible solutions.
The standard principles for WCAG are, your app must be Perceivable, Operable, Understandable and Robust.
In addition, the Axe extension and Google Lighthouse for Chrome, can test CSS content and background colors for sufficient contrast as a part of an overall accessibility audit.
Making your app perceivable is what makes users able to perceive what’s going on on your application. Applying this accessibility to your application can be done in many ways.
Alternate descriptions
Images needs to be not only specific, but also descriptive. I.E. the Alt-text for the image below would be okay with an alt-text like <img src=”pancakes.png” alt=”pancakes”>, but even better with an alt text like this: <img src=”pancakes.png” alt=”stack of blueberry pancakes with powdered sugar”>
However, what is not recommended for alt-text is leaving it empty OR stuffing it with SEO keywords.
Captions for video / sound material can help the hearing impaired users follow along. It is equally as important to match color contrast to the standards of accessibility as even having the captions in the first place.
Present content using semantic HTML
Adaptable design
It’s a good thing to include adaptability to your design, making sure each view looks equally good in all orientations. (such as Portrait / Landscape)
Visual cues
Making sure your visual cues appeal to everyone, including the colorblind. This can be done in a variety of ways. If you take the following image as a stand-point:
Then you can see how a person with red-green color-blindness is affected by a color-only validation system. To prevent this ambiguity, a way to display validation, can also be granted with either a check mark icon popping up when validation goes through, and an x icon when it fails. That is just one of many ways validation can be queued visually.
Avoid auto-starting video or audio
The simple explanation to why, is auto-started audio interferes with screen readers. Any sounds 3 seconds or longer, should come with the option to pause the sound, or lower the volume of the audio.
Responsive body copy
Keeping text for a maximum of 80 characters per line, and having sufficient line-height. The definition of sufficient line height according to the WCAG is minimum 1.5 line height between lines, and 2.25 between Paragraphs.
Text should also be legible at 200% zoom, users should not have to use horizontal scrolling to read a piece of content.
Keyboard Navigation
All accessible elements on a page must be accessible using the tab key. All users must also be able to exit an interface in an app. Inescapable key-board interfaces are known as keyboard traps.
Making sure that everything a user navigates is obviously in focus, is also a part of the WCAG. Browsing an application with weak focus indicators is practically the same as navigating a cursor with no opacity, you just don’t know what you’re clicking.
Allow enough time
If the essential functions of your website are time-based, then and only then, are you allowed to only allow your users to use the remaining time of your function. e.g. if you’re hosting an auctioning application where people can buy things within a time-limit. Otherwise if you have forms that have time-limits, then you are required to give users that need more time, the time they need to fill / use the forms or functions.
Disable distracting content
Content like video-animations, gifs, ads with sound should be an option a user of your system can turn on or off, because it can impair concentration and intent
Flashing animations
Be careful using flashing animations as content, we’ve all read the photo sensitivity and epilepsy warnings when using entertainment consoles, but in case that you haven’t
Helpful navigation
Breadcrumbs, sub-categorization, proper semantic markup. This area is not too well documented as of June 2021, but more might be available once the Mozilla documentation Network gets a proper guideline set up on how to build keyboard-only navigators.
General helpful information
Help users understand where they are with a proper title tag.
Make clickable links descriptive, when screen reader users tabs to navigate, they only get the link text read out loud.
Keep a nice structured heading hierarchy
Use form labels meaningfully
Provide alternatives to complex interactions
Provide generous target sizes to buttons. Apples design guide suggests a minimum of 44 x 44 px (44 pixel points)
Screen-readers must be able to know what language to use, and/or which accents to use.
Setting the language of a page can be done in the html tag.
<html lang=”en”>
or if a specific piece of text is in a different language, then it can be set for the specific piece of text
<p lang=”dk”>Som Jeg gør her :)</p>
Plain Language
To clarify what plain language means, there are
But to list some out, the recommendations are the following
Use strong, simple words.
Short paragraphs
Clearly organized information
Have a conversational tone

A good example of plain language from :
Create predictable navigation
To let users have a feeling of knowing what to expect while browsing your website. This also means keeping the way of navigating your site consistent.
No unexpected changes in context
People only expect major changes when initiating certain actions, like these:
Interacting with an interface element
Opening a new window
Loading a new page
Significantly rearranging page content
Moving focus to a new component.
The Mozilla developer network says on the subject. “People don’t want interfaces to surprise them. They want things to be intuitive and behave as expected”
Input assistance
They include information on
Making messages easy to notice and understand
Highlighting errors visually
Keeping instructions simple
And even more.
The final element of the WCAG “Robust”, states that content must be robust enough that it can be interpreted by a wide variety of users, including users using assistive technologies.
What does that mean in practice?
It means that we must make sure our HTML is valid while using correct semantic markup.
Use validators to make sure your errors get caught before being released, everyone can make mistakes!
It can even check for misused semantic elements.
The Robust principle also demands use of status messages to elements that adds content to a website, like Javascript that might add list elements to a site without refreshing the page.
To help developers debug accessibility,
Working accessibility into practice
The first tool that’s readily available is
The benefit of the checklist above, is that it visualizes the important elements of the WCAG guidelines. The PDF is even interact-able, meaning you can copy it and use it for multiple projects, or even print out copies to share with the working team.
An important note is however, just because you follow every guideline on the checklist, does not mean you will automatically end up with an accessible solution. It is a good idea to always have accessibility in mind when developing, and equally important to have everyone you work with on a given project, to keep it in mind as well.
It should be natural to start considering accessibility, even as early as in the research / design phases of a project.
Involving disabled users in user testing is equally critical. As for today, the rewards of developing accessible solutions, outweigh the costs by a large margin.
Form usability
According to the , over 40% of users abandon shopping carts in checkout due to difficulties with form usability, and users not being able to pass form validation. In turn, the user then abandons the cart and searches elsewhere for the product they’re looking for.
The principles of an accessible form are listed below.
Avoid unnecessary questions
Minimize questions per screen
Provide context clues
Group related questions
Use clear input labels
Make focus indicators obvious
Help users spot and correct errors (Refer to Understandable, Input assistance in the doc.)

To avoid making forms difficult to deal with for everyone, generally avoid making forms too long. A term in web development that allows people of all cognitive levels to fill in a form is called Chunking. When chunking a form, you break it down into several smaller sections where each section is a step of the form.
It’s important that when chunking a form you need to make sure all of below is true:
You are reminding the user of the purpose of the form
The form contains a clear label of the current step
The user knows how much of the form that has been filled in
The user knows how much of the form is remaining

When all of above is true, users with cognitive disabilities or memory impairments, can still relatively easily complete a form.
When it comes to helping the user write what’s in the form. Placeholder text is generally a bad idea, either if the text in the placeholder is too light, visually impaired might not be able to read what the placeholder text says. If it’s too dark, it can be confused with preloaded data in the field. A better solution to placeholder text is input masks.
It’s better to format the users data when they’re done writing it, than trying to nudge them in the right direction before they start writing.
Front-end Web Optimization
Simple Steps for easy Web Optimization
Here’s a short list of simple steps you can take to improve load-times:
Create a performance budget so you have a reference of what you can and can’t do to your site.
Use properly sized images or include an image resizing tool
Make sure You’re not including libraries that you’re not using.
Make sure You remove / comment out code that doesn’t work
Generally, reduce your HTTP requests to a viable minimum.
Use Content Delivery Networks for your imported js libraries.
Make & use spritemaps for your frequently loaded templates (i.e. Footer, Header etc.)
Minify your CSS & JS.
Ajax Basics
Simple structure of AJAX
an AJAX request starts with the creation of the XMLHttpRequest object.
It can be created as a variable.
var xhr = new XMLHttpRequest();
Different functions can be run depending on what readyState the object is in. The four different readyStates an XMLHttpRequest has are:
0 - request not initialized
1 - Server connection established
2 - Request Received
3 - Processing Request
4 - Request Finished and Response Ready.

So if you would run something when the request is ready, you could pack the AJAX request like this:
xhr.onreadystatechange = function () {
if(xhr.readyState === 4) {
//do some javascript here;
When the function is written and ready to be sent to the server for processing, You then need to open a connection, stating what kind of request you’re making, and what file / resource you want to use.
This is done by executing the open and send methods on the xhr object.'GET', 'resource.html');
The best thing about this setup is you can tie it all together with button elements or forms on web applications.
A final example of how this could be done:
var sendAJAX = () => {
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function () {
if(xhr.readyState === 4) {
document.getElementById('ajax').innerHTML = xhr.responseText;
};'GET', 'sidebar.html');
document.querySelector('#load').style.display = 'none';
<h1>Bring on the AJAX</h1>
<button id="load" onclick="sendAJAX()">Bring it!</button>
The following example requires you to have a web server that is ready to serve the file sidebar.html - it wont just work as is, as it requires an elaborate setup. This is just a code-snippet example.
Generally when talking POST vs GET the gist is you’d always use a post method to send and save data to a database. You would use GET to retrieve specific information, but why? What are the limitations of both request types?
If you want a generalized set of key differences, skip to Key Differences of POST and GET.
Main features of GET:
It is very easy to bookmark data using GET method.
The length restriction of GET method is limited.
You can use this method only to retrieve data from the address bar in the browser.
This method enables you to easily store the data.

Main Advantages of GET:
The GET method can retrieve information identified by the request-URl (Uniform Resource Identifier).
GET requests can be viewed in the browser history.
It enables you to save the results of a HTML form.
You can easily use GET method to request required data.

Main Disadvantages of GET
GET can’t be used to send word documents or images.
GET requests can be used only to retrieve data
The GET method cannot be used for passing sensitive information like usernames and passwords.
The length of the URL is limited.
If you use GET method, the browser appends the data to the URL.
You can easily bookmark Query string value in GET
Main featuers of POST:
POST method request gets input from the request body and query string.
Data passed using the POST method will not visible in query parameters in browser URL.
parameters of POST methods are not saved in browser history.
There is no restriction in sending the length of data.
It helps you to securely pass sensitive and confidential information like login details to server.

Main advantages of POST:
This method helps you to determine resource URI.
Specifying a new resource location header is very easy using location header.
You can send a request to accept the entity as a new resource, which is identified by the URI.
You can send user-generated data to the web server.
It is very useful when you do not have any idea about the resource you have to keep in the URL.
Use POST when you need the server, which controls URL generation of your resources.
POST is a secure method as its requests do not remain in browser history.
You can effortlessly transmit a large amount of data using post.
You can keep the data private.
This method can be used to send binary as well as ASCII data.

Main disadvantages of POST
It is not possible to save data as the data sent by the POST method is not visible in the URL.
You cannot see POST requests in browser history.
This method is not compatible with many firewall setups.
You cannot use spaces, tabs, carnage returns, etc.
This method is not compatible with some firewall setups.
POST method takes lots of time when uploading the large binary file.
Key Differences of POST and GET
In GET method, values are visible in the URL while in POST method, values are NOT visible in the URL.
GET has a limitation on the length of the values, generally 255 characters whereas POST has no limitation on the length of the values since they are submitted via the body of HTTP.
GET method supports only string data types while POST method supports different data types, such as string, numeric, binary, etc.
GET request is often cacheable while POST request is hardly cacheable.
GET performs are better compared to POST.

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.