Dinosaur JS

Re-Learning Accessibility for a Decoupled Front End

Mediacurrent Team — Wed, 04 Oct 2017 14:45:53 +0000

Re-Learning Accessibility for a Decoupled Front End

Recently, I was lucky enough to catch a workshop by Brian Sinclair entitled 'Accessibility: The Basics and Beyond.' The workshop was part of the DinosaurJS conference in Denver CO.

As part of the accessibility group at Mediacurrent, I was excited to see the issue being addressed at a javascript conference.

Since the launch of Drupal 8, front-end developers have had to pay a little more attention to either including or not excluding the accessibility features of Drupal. As decoupling the front end from Drupal is becoming more common and we use frameworks like Vue or React to provide the user interface, we need to make sure that we understand what we need to do accessibility wise to make sure that our sites and applications are available to all. If we are writing the markup, we need to make sure that we are aware of the HTML accessibility requirements without relying on the work of Drupal’s accessibility team.

What a good time to get a refresher on basic accessibility - why we do this, and how to use the docs.

So one of the main takeaways from the ‘Why we do this?’ section was that improved accessibility means an improved user experience for everyone. When we are focused on how things work for people who are accessing content in different ways, we are more conscious of how our site works. This mindset has the benefit of improving the experience for all users. In other words, ‘solve for one, extend to many.’

The ’Tools’ section of the presentation was extremely insightful. This centered around the WCAG 2.0 guidelines. Despite having been on the accessibility team for a year and reading this site many times I had not noticed how the guidelines were grouped. The sections are an acronym, POUR. Which stands for:

Perceivable - can everyone consume this content?

Operable - can you use it, can everyone use it, tab, enter etc.

Understandable - Does the content even make sense? Can someone use the site without explanation?

Robust - Can it be used in a broad variety of environments?

This is likely obvious, however, I had not made the connection and this really changed my perception of the guidelines. By understanding what each section was targeting, and relating each section to each other it really helps approach projects and issues with greater confidence.

When discussing the levels for WCAG 2.0, which range from A through AAA, AA is the target that most accessibility teams aim for. However knowing your audience is as important as adhering to standards. In Brian’s example he pointed out if your website or app is only available for Apple users, then there is little benefit to supporting internet explorer. The same is true for accessibility. You might not need to provide an extremely robust screen reader support if all users are using the built-in Apple voiceover. Sometimes it is not useful to say ‘we have to meet every AAA standard, or even AA’ if the site content doesn’t suit that need.

Another big takeaway from the tools sections was that the software tools we use when testing our sites to make sure that we are not overlooking any areas are not 100% foolproof. Things like aXe and Wave will catch some of the errors and oversights but are no real guarantee that you have hit everything. It is also worth noting that some items that are flagged may not be either desired or required. For example, sometimes providing alt tags for images that serve no useful information to a screen reader is better than bombarding the screen reader with information. The main takeaway for me was that we always need to be thinking about what we are presenting and how it is being viewed. If we can justify the decisions that we made then we will be in a better place for future iterations.

Overall I found this presentation to be very useful. I try to attend all of the accessibility talks at the conferences I go to because I think it is important to support the work but also it is good to make sure that I am on the right track for current approaches. As we work on projects where we can’t fall back on provided HTML structure, it is important that we understand how to get the information we need and access the tools available to us.

Mediacurrent Team Wed, 10/04/2017 - 10:45

Persona

Drupal Developer

Blockchain: Long Thoughts

Mediacurrent Team — Fri, 08 Sep 2017 15:00:26 +0000

Blockchain: Long Thoughts

First thoughts...

It has always been said that “the book is better than the movie.” This blog post gives a behind-the-scenes look at the writing that inspired the Friday 5 video.

Why?

Due to the Mediacurrent Friday 5 being a series that lasts 5 minutes, and the unfortunate absence of a suitable ”Friday half hour to 45 minutes” show, the content would be again, reimagined.

This script stands as the predecessor to the current Friday 5 script.

What is the Blockchain?

Back when I was at Dinosaur JS in Denver this past June, I first heard mention of the Blockchain. During the talks, twice I think, there was mention of this [visible air quotes] “Blockchain”, and how it was secure. I did not pay it much attention at the time, aside from writing it down in my notes with a few question marks, but it seemed like a topic worthy of looking up later.

Fast forward a week or so later, when I finally got the opportunity to review my notes, I finally came to understand what the Blockchain was. I did not realize it was so … elegant.

Now I like code, in all it’s forms, nuances, and undertones. So when I say that it is elegant, it’s because it’s code, open-source code, and it has solved great problems in the digital world.

More than anything, it has solved ownership and identity in the digital landscape. No middle-men; just undeniable proof of ownership via the Blockchain.

By definition, the Blockchain is:
An incorruptible, distributed digital ledger of transactions; one that is “secure by design”.

A ledger that is broadcast openly to all, so that the network as a whole can validate.

Now even though the word transactions was used, this does not insinuate that the Blockchain is financial. Transactions can include any data, an individual’s identity, and pretty much anything that you would note in a ledger.

It is a cool concept once you understand how it all works.

Applications

Before we discuss how this all works, I wanted to take a moment and express that we are not diving into the different applications built using the Blockchain.

The majority of Blockchain topics center on Bitcoin, and there are a few things worth noting here:

Bitcoin is NOT the Blockchain.
Bitcoin is a financial application built using Blockchain technology.
This is not a discussion on BitCoin.
This is a discussion on the technology that is the Blockchain.

The Block chain is a technology that could be the next innovation to shake the world up.

Applications can range from file storage to fully secure voting systems.

During all my research on the topic, I came across some content that really put this into perspective for me.

Throughout our history, there have been various innovations that changed the world as it was known.

The printing press powered the spread of knowledge across the globe.
The combustion engine, and its direct effect on manufacturing and travel.
Even the Internet stands as a technology that defined the landscape of life after its creation.

Each of those had an insurmountable impact on the world and everything in it. They touched every aspect of life.

There is a resource out there on the web, my apologies for not having the citation, that made an interesting point. Each and every business and organization is officially in competition with a Blockchain version of themselves. Now I can't speak to the validity of that statement; but if it is true, then you can start to understand the full scope of possibilities.

How does the Blockchain work?

So let’s get into this! Imagine if you will…

We start with a single ledger of data, or a block. This block exists as a listing of transactions and changes within the data model. We take this block, run some cool cryptology on it, then string it along with all the blocks that came before it in a “chain”. Hence the Blockchain; a chain of blocks!

Righteously original name though.

Oh; and about that cryptology. See, using the normal private/public key methodology that we use in programming for encrypting data, a hash ID is created for each individual block. This hash is created from 4 things:

The owner’s private key
The owner’s public key
The data in the block.
The hash id of the block in the chain before it.

Yeah ... #4 ..That is where it gets kinky. If each block’s hash id includes the hash id of the parent block before it, it creates a dependency. As such, you cannot alter a block higher up the chain without directly affecting each block that follows in the cascade.

You would be rewriting history.

This is where the security aspect of the Blockchain start to appear. The older the block is in the chain, the more the chain’s hash IDs collectively meld together; the more secure it becomes.

This, of course, assumes that the entire chain could not be re-written/replaced with a different version. This is the “double-spending” paradigm. The ability to assign ownership of something to two individual parties; defrauding one. An issue that only the Blockchain has been able to solve in the digital world.

Normally, addressing the “double-spending” paradigm requires the use of 3rd party intermediaries; like banks or the DMV. They bridge the gap between validating various transactions.

Something that is only possible if the security of the chain was not an issue.

So how do we ensure that the chain is secure and unaltered?

Easy … Open source, baby!

Open source

Yeah man. Just like our beloved Drupal, everything you need to start, maintain, and whatever, is open source and available on the web. You could go get it right now.

Grab the software, power up and machine, and (typically) join a mining pool; a subsection of the entire network. A giant network of computers, “nodes”, sharing the weight of the required computational power to validate new blocks on a chain.

This is a great strength of Blockchain technology. Because the Blockchain is a decentralized network, there is no centralized point of weakness. Each node on the network holds the same Blockchain, and the same tools for decrypting and validating new blocks for inclusion in the blockchain.

So we take that ledger and all the blocks that lead up to it and replicate it across a vast network. Each node, or computer, on the network would receive the broadcasted the blocks as they are generated.

Each node then begins the computational processing needed to validate the block. Valid blocks that pass all rules are added to the chain; invalid blocks are given da boot.

Therefore, in order for a block to make it into the chain, all of the nodes must agree that it is valid; not just one.

So going back to the “double-spending” paradigm. it does not matter if you can rewrite the entire Blockchain; you cannot rewrite the entire network. Especially not fast enough to thwart every other node in the network before it is noticed and kicked out as invalid.

All of these nodes are playing a critical role in the system. They are the “miners” that provide the computational power necessary to keep the chain flowing.

Remember that long chain of blocks, you can imagined the amount of electrical power that is required to validate a block. This requirement is then distributed across the network.

And the network works together to maintain the integrity of the Blockchain.

Secure by Design...

Final thoughts

The Blockchain provides a solution to many problems. Likely more than we even know exists.

Just think of where we are today vs when the Internet was created. There is no way to truly know the full scope.

Perhaps it leads to great success; perhaps to great pain. It is really in the hands of creative people at this point.

But the potential is there. Could you imagine a world where digital security was inherent? Or even imagine a world where voter fraud was just not possible. Regardless the context of the election, having the means to 100% legitimize each and every vote in the ballot box is huge. In the digital landscape, where you cannot trust the identity of the person on the other side, the Blockchain steps into the equation to provide a solution.

All from a pseudonym known as Satoshi Nakamoto. As an innovation, the Blockchain is powerful. And yet, the true identity of Satoshi Nakamoto remains unknown.

During my research, I saw mention that the creator still maintains an amount of unspent Bitcoin valuing over $2 billion dollars. All with a technology that was given to the world freely.

Yes…

I dare say it again…

The Blockchain is elegant.

Mediacurrent Team Fri, 09/08/2017 - 11:00

TypeScript and Drupal.behaviors

Peter Mallett — Fri, 18 Aug 2017 15:05:06 +0000

TypeScript and Drupal.behaviors

Back in June some of our crew attended Dinosaur JS conference in Denver, CO.

There were talks ranging from V8’s JS optimization (even had some assembly language slides in there) to demonstrating the creation of an homage to an abstract artist with JavaScript code.

This all got me thinking about TypeScript, Closure compiler, etc... and JS performance and development in general. But I have to admit, I was struggling to see how these technologies could benefit us in Drupal since most of our JS is done in Drupal.behaviors.

Compilers

Backing up a bit, way back to the days of yore, March 2017. Over the past several months I have been tinkering on a small project written in C here and there. One thing I keep being struck by is: the ability to lean on the compiler when refactoring is really nice. Want to remove a member from a struct? No problem, the compiler will tell you any place that it was accessed so you can review the code for further needed changes.

We don’t get to do this with JavaScript since everything is only checked at runtime, but what if we could?

Meanwhile… at Dino JS

During our trip to Colorado, I attended a workshop for getting a project up and running with TypeScript. During a section when features of the compiler were presented I thought: “wouldn’t it be nice if we could use common TypeScript interfaces in Drupal behaviors so that when there’s refactoring, we could lean on the TypeScript compiler, too?”

And it turns out we can.

Demo time!

I started out with the Mediacurrent Drupal theme generator, which is really cool!

Check out Mario’s post about that here: https://www.mediacurrent.com/blog/mediacurrents-drupal-theme-generator

This way I was able to get a new theme created with two example components with behaviors in a few minutes.

From there I added a gulp task in my theme (called “generated”) to handle my TypeScript code.

Note: this is not final, I just sorta jammed this in here for a test. In a production project, this would probably be a build task like the rest of the theme.

I added some simple jQuery code to CardA, and CardB to simply add a border for illustration and now you can see my two .ts behaviors are slotting into the theme just as if I had written them in es6:

But here’s the fun part! If I make a new Interface:

And then use that interface in two or more places:

And then later that Interface undergoes some changes:

Next time I run the compile task:

Yay! Now we see all the places in the project where the change to the shared interface affects the code because tsc will tell us about them.

If you’re using Visual Studio Code, it tells you right in the IDE as well:

So, is it worth it?

At this time I would say: “maybe”. If your project is already using gulp for transpiling steps, this doesn’t really change that much. You just now write things in TypeScript and you are able to benefit from the compile-time type checking.

For a large project where you have many behaviors that all have to do processing on the same types and data structures? I would say it is almost definitely worthwhile.

Taking things further...

Beyond the maintainability benefits gained from tsc in this little demo, we could add Google’s Closure Compiler into the mix as well. Then we’d be leveraging our type-checked code output into a more performant optimized bundle.

In order to translate from TypeScript to code that Closure Compiler can work on there is a transpilation step required. Good news, though, there’s a tool from the Angular project available called Tsickle which does just that allowing Closure Compiler to take advantage of type information from TypeScript.

Helpful Links:

Potential benefits recap:

Shared interfaces, nice code completion in an IDE
Updates to shared interfaces help with refactoring and catching issues before they present as runtime bugs
Visual Studio Code automatically integrates TypeScript and gulp out of the box
Gain better performance through the use of Closure Compiler after translation through Tsickle

Peter Mallett Fri, 08/18/2017 - 11:05