The American Disability Act (ADA), 1990 provides provisions to secure the rights of specially-abled people. Although, when first passed, it focussed primarily on physical properties, over time it has covered digital spaces too, which means people can take a complaint to the court for discriminating and violating the ADA act.

Accessibility is a more accepted norm when it comes to physical infrastructure, however, when accessibility translates to the digital space, industries across the web are struggling to answer. Higher education is no exception.

“The National Association of the Deaf in 2015 slapped Harvard University and Massachusetts Institute of Technology in Massachusetts federal court, accusing them of discriminating against deaf and hard-of-hearing people”

An absence of hard and fast rules to adhere to in the higher education sector often lead institutes to ignore the web accessibility practices.

Exploring the Issues in Higher Ed and the ADA Compliance

Lawsuits can be avoided by following WCAG 2.0. Since web accessibility guidelines and best practices are already clear through WCAG 2.0.

The ADA Compliance

The ADA not only covers the general non-discriminatory guidelines but also encourages organizations, institutions, and businesses to provide accommodations to people with disabilities so they can have the same level of access to services as everyone else.

The law was amended later in 2008 to fit the conditions of modern society and include the digital space while broadening the term “disability”.

Since, ADA conforms to other state laws, including section 508 of the Rehabilitation Act and existing WCAG 2.0 guidelines, hence the term - ADA Website Compliance. In January 2017, the federal government adopted the Web Content Accessibility Guidelines, (popular as WCAG 2.0) setting the standards with A and AA level for all websites.

The Guiding Principles to Web Accessibility - POUR

The WCAG 2.0 consists of 12 guidelines with four arching principles of POUR. These guidelines relate to one simple question: can the users with varying degree of ability ingest the content on your site?

“Just as no ramps would exclude people with a wheelchair, videos without caption exclude people who are hard of hearing.”

Accessibility in higher education should not be restricted only to lectures and videos. In the case of a flash-based campus tour, there should be alt-text for visually impaired people. Accessing content should be intuitive. Making navigation easier needs to be part of the plan.

PerceivableOperableUnderstandableRobust

Perceivable

The content needs to be presented in different ways, including assistive technologies, without losing its meaning. The easiest way to do so is by providing alt-text for non-text content. The content should be easier to see and hear.

By no means should the multimedia content be unattainable. In the case of Harvard and Massachusetts Institute of Technology, the content was not perceivable for the deaf and hard-of-hearing people.

Story of Harvard: Harvard and M.I.T. have extensive free materials online, distributed across platforms like Harvard@Home, MIT OpenCourseWare, YouTube, and iTunesU, edX which offers extensive massive open online courses (MOOCs), free to students around the world.

The videos either did not include captions or were inaccurately captioned (read unintelligibly) making it inaccessible for people with hearing ability.

"Accessible" means fully and equally accessible to, and independently usable by, differently abled students and faculty members in a way that they can acquire the same information, engage in the same interactions, and enjoy the same services as sighted students and faculty with substantially equivalent ease of use.

Operable

This principle ensures that the content is easy to operate upon. Web accessibility issues are not synonymous with visibility issues, as is the popular myth. They are as much a problem for people with hearing disability as for a person with a neurological or cognitive disorder.

The content on the website needs to be accessible with a keyboard for people with limited motor functions, people with color blindness, and avoiding the use of content and types that cause seizure.

“People living with reflex epilepsy have seizures that occur in response to a specific stimulus, like flashing lights or by noises.”

Understandable

Is the text readable for people with difference in visual ability? This principle ensures that the content appears and operates in a predictable way. This specifically focuses on the issues related to color contrast.

Accessing content should be intuitive and easy. To disable the pop-up button or going back need not be a time-consuming exercise.

Atlantic Cape Community College in 2007 was dragged to court by a visually challenged student after the campus and curriculum proved to be a challenge for him.

Robust

Any content - written or multimedia - should be future proof. Efforts should be made to maximize compatibility with current and future user tools. Before the dawn of the 21st century, screen readers were not as popular as they are 18 years later. A decade back even mobile phones were not as ubiquitous.

Assistive technologies are advancing by leaps and bounds, and your site needs to adapt and step up with upcoming trends in hardware and software tools. In order to keep the content robust, higher ed institutes need to adhere to best practices or lose it the way University of California, Berkeley did.

“In a similar scenario in 2017, The University of California, Berkeley, in response to a Justice Department accessibility order, had two options:

1. Update existing content to comply with accessibility standards.
2. Remove more than 20,000 video and audio files from public view.

They chose the latter, the digital equivalent of boarding up the entrance to a building instead of installing a wheelchair accessible ramp.”

Checklist: Making Higher Ed Institutes ADA Compliant

In its defense, the Harvard University asked the court to propose rules “to provide much-needed guidance in this area”. This is one of the most infuriating aspects of accessibility compliance in higher education – there has been an absence of hard and fast rules to adhere to. Something that echoes the statement of Harvard.

Now that we understand the guiding principles, we are in a better position to deliver a better user experience to all. One thing worth highlighting is - accessibility issues are easier to address before they manifest on your site, not after.

“It costs significantly less to make a site accessible than it does to procure the lawyer to protect you in an accessibility claim.”

Under WCAG 2.0 priority levels are assigned to each checkpoint based on its impact on accessibility. These levels were the following:

Priority 1: Conforming to this level will make it possible for one or more groups to access the web content. This is level A.Priority 2: Conforming to this level will make it easy for one or more groups to access the web content. This is level AA. Priority 3: Conforming to this level will make it easier for most of the groups to access the web content. This is level AAA.

Provide web pages with titles that describe the topic or purpose of the page.

Make sure it is navigated in a meaningful manner while providing the options to bypass repeating blocks of content on multiple pages.

Make sure that the purpose of each link can be determined by the link text alone unless the purpose is ambiguous to all users.

In case of an input error made by the user, provide text information specifying the item in error and the error itself.

Provide labels, guidance and instructions, and text alternatives for all non-text content. Controls or input fields must have a name describing their purpose.

Information must be accessible to different users in multiple ways, including through assistive technologies (such as screen readers) without losing information.

Using colors that convey visual information, distinguishing visual components, indicating actions or prompting for a response.

Users must have the ability to fully operate the website through a keyboard interface, including the ability to pause and stop any presentation, audio or adjust the volume.

Content must not cause seizures. Avoid designing content in a way that is known to cause seizures.

Compatibility with other user software, like the ones in assistive technologies.

Level AA Conformance - other than those in level A

Provide captions for all live audio content. And provide audio descriptions for all pre-recorded video content.

Text content and images of text must have a contrast ratio of 4.5:1. Content that serves only design purposes have no contrast requirements.

Enable the user to resize the text up to 200 percent without any assistive technology.

Use of text over images, whenever possible.

Provide multiple ways to locate web pages.

Ensure the keyboard focus indicator visibility through all interfaces.

Components with the same functionality must be identified consistently.

Ensure the security of legal and financial data transactions by making them reversible, and giving the user an opportunity to recheck the input data and the confirmation mechanism before finalizing submission.

Level AAA Conformance - other than those in level A and AA

Support all pre-recorded audio content with sign language interpretation and provide extended audio descriptions for all prerecorded video content where there’s no opportunity to pause the foreground audio and provide audio descriptions.

The contrast ratio between text and images must be 7:1. However, text or images which serve only design purposes do not require contrast or alt text.

Any pre-recorded audio content must provide users with context-sensitive help. In case the audio-content is not a CAPTCHA it should either:

must not contain any background sounds

or the background sounds can be turned off,

or the background sounds should be at least 20 dB lower than the pre-recorded speech content.

Provide users with a mechanism to choose foreground and background colors. With the width of blocks of content must not exceed 80 characters or glyphs.

Line spacing must be at least 1.5 spaces within paragraphs and paragraph spacing must be at least 1.5 times larger than the line spacing.

Ensure the text can be adjusted up to 200 percent without the use of assistive technologies. The user does not have to scroll horizontally to read a line of text.

Allow users to postpone or suppress interruptions, except in the case of emergency.

Ensure the users can continue their activity without much interference or loss of data after re-authentication in case the authenticated session expires.

Include information on the user’s location within a set of pages. Provide supplementary content for identifying definitions of unusual words or phrases, including idioms, abbreviations, and jargon.

Changes of web content may only be initiated by the user or the user must be provided with a mechanism to turn off such changes.

It is worth noting that web accessibility compliance may not be realistic for all websites depending on the type of content. Drop a mail at hello@opensenselabs.com and connect with us if you are planning to build a user-friendly education website.

Meet John. He is running a business. He is a digital agency owner and a CEO and currently employs 25 people of different profiles. Account managers, designers, developers, project managers, sales & marketing people,... And the business is going well for John and his team. In fact, so good he needs more bandwidth for his development team. They are already working long hours and with recent sales push giving first results and getting two new clients on board his team will need reinforcements. Because the existing team won't be able to handle the extra workload.
What are the… READ MORE

The third edition of the annual Drupal Business Survey is here. Exove and One Shoe created the survey in collaboration with Drupal Association, to gain insight of Drupal’s health, focus and latest business trends. It also gives perspective on how Drupal agencies are doing and how customers see Drupal.

Analysis of the 2017 edition of the survey can be found here, and 2016 analysis here.

We encourage all Drupal business leaders to participate in this year’s Drupal Business Survey.

Participation is anonymous and takes only about 10 minutes. The first results will be presented at the Drupal CEO Dinner at Drupal Europe on Wednesday, September 12, 2018. Analysis and insights will officially be published on Drupal.org.

Drupal is fantastic for all sorts of websites and applications. It excels especially at large, complex content projects. If you know what you are doing, you can often cut development time substantially compared to other tools made for the same purpose.
Drupal's versatility, however, is a 2-edged sword. With great flexibility, extensive API and an abundance of modules created by the community, it takes a long time to get up to speed. Often there is not enough time on a project to go through Drupal's steep learning curve.
The more experienced your team is, the more benefits of Drupal you will reap and the less technical debt you will acquire, and the more successful your project will be in the end.
Looking for a Drupal team
There are a few critical elements you should consider when you are looking for to outsource a Drupal project:

With a uniquely diverse community of designers, developers, and everyone in between, Frontend United is one of the conferences I find I enjoy more and more each time I attend. And this time, in Utrecht, a wide range of designer- and developer-oriented content greeted attendees both within and well outside the Drupal universe.

The best part of my job is teaching Drupal. As a Drupal trainer, I get to meet a lot of Drupalers with really different backgrounds. Some are brand-new to Drupal, some have lots of experience. Listening to them tell of their Drupal journeys, both the highlights and the low points, has given me insights into the different ways people encounter Drupal and some of the most common reasons why they love it, use it and get involved in the community (or not).

I've recently been thinking about the Drupal community from a user experience point of view. I regularly host UI meetups for developers and designers, and I'm also volunteering on Drupal's Admin UI initiative, which is creating an accessible administrative interface based on user data and feedback. Both have taught me to empathize with others and understand why they might be feeling excited, warm and fuzzy, anxious, frustrated or curious about Drupal at any given point. It's also given me ideas about what we can all can do to improve the Drupal experience, including:

1. Participate in the community

If you think back to your own best experience with Drupal, there's a decent chance that it was a DrupalCon, DrupalCamp or another time when you had the chance to learn from other Drupalers or share your knowledge with them. It feels inspiring to mentor newcomers, help people solve problems on Drupal Slack or get advice from someone who seems to care. Let's keep it up and look for opportunities to take it further!

2. Recognize the challenges that you and others are facing

There's no point in pretending that using Drupal is always smooth sailing. Hiding the challenging parts of our experiences only makes others feel like they're alone or that they've missed something everybody else has understood. Asking new users around the world to tell me about their pain points has shown me, as just one small example, that Drupal terminology can often be intimidating. We all have our issues, and talking about them is the first step toward finding solutions for them.

3. Get involved with existing initiatives

Community members are on the job when it comes to refining certain aspects of the Drupal experience. The Promote Drupal Initiative has already enhanced Drupal.org's landing page with the persona-specific information its audience was looking for. Their next step will be devising ways to make it easier for new users to find their way into community engagement. And they're not the only ongoing project that could benefit from your time, expertise or financial support: the Out of the Box Experience Initiative, for example, is helping Drupal to make a better and more helpful first impression when it's installed by a prospective user.

4. Imagine new ways of solving problems

The beauty of being part of an open source community is that if you see a problem, you have the power to address it. If you have an idea for helping others have a better Drupal journey, why not try it out? Great user experiences encourage user-base growth and vice versa: a virtuous cycle that I'm committed to supporting.

Inspired by these ideas, I recently decided to run for a position on the Drupal Association's Board of Directors as a "director at large"---a community representative, in other words---because I would love to put my time, energy and knowledge towards growing the community and promoting Drupal to new groups and markets. If you have an active profile on Drupal.org then you can vote in this election here any time before Friday, July 13.

For a video version of this post, here's a recording of my session on the topic at DrupalCamp Montreal:

Drupal is fantastic for all sorts of websites and applications. It excels especially at large, complex content projects. If you know what you are doing, you can often cut development time substantially compared to other tools made for the same purpose.
Drupal's versatility, however, is a 2-edged sword. With great flexibility, extensive API and an abundance of modules created by the community, it takes a long time to get up to speed. Often there is not enough time on a project to go through Drupal's steep learning curve.
The more experienced your team is, the more benefits of Drupal you will reap and the less technical debt you will acquire, and the more successful your project will be in the end.
Looking for a Drupal team
There are a few critical elements you should consider when you are looking for to outsource a Drupal project:

React.js is a very popular JavaScript framework created by Facebook. It allows you to build beautiful, interactive and fast interfaces, with which users will fall in love. Drupal, on the other hand, is a fantastic CMS with you can build small, medium and huge websites.
Sometimes you want to pair the two frameworks together - offer sophisticated Drupal backend, and a slick, quick frontend based on React. That is when Drupal and React can come together.
In this post, I will explore various methods of combining the technologies.
Headless Drupal vs. embedded React
The primary choice you have to make when using React with Drupal is whether you want to use a "headless Drupal" approach where Drupal is only in the backend and React is the only interface user ever sees or whether you just want to add a React app to the Drupal website rendered by the Drupal templating engine. Let me elaborate.

Set Up a Local Drupal Site with Lando in no Time: Get Started with Docker
radu.simileanu
Tue, 07/10/2018 - 11:30

Let's say that you need to spin up a new Drupal environment in... minutes. To quickly test a new patch to Drupal core, maybe, or to switch between 2 or more clients on the same day and thus to run multiple copies on several websites... In this case, how about taking the quick and easy way and set up a local Drupal site with Lando?

"What is Lando?" you might legitimately ask yourself.

A DevOps tool and Docker container-based technology enabling you to spin up all the services and tools that you need to develop a new Drupal project in no time.

then Drupal will have a non-NIH (Not Invented Here) API but one that follows a widely used spec

it enables them to build progressively decoupled components

…

So where are things at?

Timeline

Let’s start with a high-level timeline:

The plan (intent) to move the JSON API module into Drupal core was approved by Drupal’s product managers and a framework manager 4 months ago, on March 19, 2018!

A core patch was posted on March 29 (issue #2843147). My colleague Gabe and I had already been working full time for a few months at that point to make the JSON API modules more stable: several security releases, much test coverage and so on.

Some reviews followed, but mostly the issue (#2843147) just sat there. Anybody was free to provide feedback. We encouraged people to review, test and criticize the JSON API contrib module. People did: another 1000 sites started using JSON API! Rather than commenting on the core issue, they filed issues against the JSON API contrib module!

Since December 2017, Gabe and I were still working on it full time, and e0ipso whenever his day job/free time allowed. Thanks to the test coverage Gabe and I had been adding, bugs were being fixed much faster than new ones were reported — and more often than not we found (long-existing) bugs before they were reported.

Then 1.5 week ago, on June 28, we released JSON API 1.22, the final JSON API 1.x release. That same day, we branched the 2.x version. More about that below.

The next day, on June 29, an updated core patch was posted. All feedback had been addressed!

But there’s more! All of the above happened on the 8.x-1.x branch. As described in #2952293: Branch next major: version 2, requiring Drupal core >=8.5 (and mentioned in #61), we have many reasons to start a 8.x-2.x branch. (That branch was created months ago, but we kept them identical for months.)
Why wait so long? Because we wanted all >6000 JSON API users to be able to gently migrate from JSON API 1.x (on Drupal ⇐8.5) to JSON API 2.x (on Drupal >=8.5). And what better way to do that than to write comprehensive test coverage, and fixing all known problems that that surfaced?
That’s what we’ve been doing the past few months! This massively reduces the risk of adding JSON API to Drupal core. We outlined a plan of must-have issues before going into Drupal core: #2931785: The path for JSON API to core — and they’re all DONE as of today! Dozens of bugs have been flushed out and fixed before they ever entered core. Important: in the past 6–8 weeks we’ve noticed a steep drop in the number of bug reports and support requests that have been filed against the JSON API module!

After having been tasked with maturing core’s REST API, and finding the less-than-great state that was in when Drupal 8 shipped, and having experienced how hard it is to improve it or even just fix bugs, this was a hard requirement for me. I hope it gives core committers the same feeling of relief as it gives me, to see that JSON API will on day one be in much better shape.

The other reason why it’s in much better shape, is that the JSON API module now has no API surface other than the HTTP API! No PHP API (its sole API was dropped in the 2.x branch: #2982210: Move EntityToJsonApi service to JSON API Extras) at all, only the HTTP API as specified by http://jsonapi.org/format/.

TL;DR: JSON API in contrib today is more stable, more reliable, more feature-rich than core’s REST API. And it does so while strongly complying with the JSON API spec: it’s far less of a Drupalism than core’s REST API.

So, with pride, and with lots of sweat (no blood and no tears fortunately), @gabesullice, @e0ipso and I present you this massively improved core patch!

EDIT: P.S.: 668K bytes of the 1.0M of bytes that this patch contains are for test coverage. That’s 2/3rds!

To which e0ipso replied:

So, with pride, and with lots of sweat (no blood and no tears fortunately), @gabesullice, @e0ipso and I present you this massively improved core patch!
So much pride! This was a long journey, that I walked (almost) alone for a couple of years. Then @Wim Leers and @gabesullice joined and carried this to the finish line. Such a beautiful collaboration!

(@effulgentsia and @xjm co-authored this comment.)
It’s really awesome to see the progress here on JSON API!
@xjm and @effulgentsia discussed this with other core committers (@webchick, @Dries, @larowlan, @catch) and with the JSON API module maintainers. Based on what we learned in these discussions, we’ve decided to target this issue for an early feature in 8.7 rather than 8.6. Therefore, we will will set it 8.7 in a few days when we branch 8.7. Reviews and comments are still welcome in the meantime, whether in this issue, or as individual issues in the jsonapi issue queue.
Feel free to stop reading this comment here, or continue reading if you want to know why it’s being bumped to 8.7.
First, we want to give a huge applause for everything that everyone working on the jsonapi contrib module has done. In the last 3-4 months alone (since 8.5.0 was released and #44 was written):

Per #62, the remaining bug fixes require breaking backwards compatibility for users of the 1.x module, so a final 1.x release has been released, and new features and BC-breaking bug fixes are now happening in the 2.x branch.

Also per #62, an amazing amount of test coverage has been written and correspondingly there’s been a drop in new bug reports and support requests getting filed.

Given all of the above, why not commit #70 to core now, prior to 8.6 alpha? Well,

We generally prefer to commit significant new core features early in the release cycle for the minor, rather than toward the end. This means that this month and the next couple are the best time to commit 8.7.x features.

To minimize the disruption to contrib, API consumers, and sites of moving a stable module from core to contrib, we’d like to have it as a stable module in 8.7.0, rather than an experimental module in 8.6.0.

While we’re still potentially evolving the API, it’s helpful to continue having the module in contrib for faster iteration and feedback.

Since the 2.x branch of JSON API was just branched, there are virtually no sites using it yet (only 23 as compared with the 6000 using 1.x). An alpha release of JSON API 2.x once we’re ready will give us some quick real-world testing of the final API that we’re targeting for core.

As @lauriii pointed out, an additional advantge of allowing a bit more time for API changes is that it allows more time for the Javascript Modernization Initiative, which depends on JSON API, to help validate that JSON API includes everything we need to have a fully decoupled admin frontend within Drupal core itself. (We wouldn’t block the module addition on the other initiative, but it’s an added bonus given the other reasons to target 8.7.)

While the module has reached maturity in contrib, we still need the final reviews and signoffs for the core patch. Given the quality of the contrib module this should go well, but it is a 1 MB patch (with 668K of tests, but that still means 300K+ of code to review.) :) We want to give our review of this code the attention it deserves.

None of the above aside from the last point are hard blockers to adding an experimental module to core. Users who prefer the stability of the 1.x module could continue to use it from contrib, thereby overriding the one in core. However, in the case of jsonapi, I think there’s something odd about telling site builders to experiment with the one in core, but if they want to use it in production, to downgrade to the one in contrib. I think that people who are actually interested in using jsonapi on their sites would be better off going to the contrib project page and making an explicit 1.x or 2.x decision from there.
Meanwhile, we see what issues, if any, people run into when upgrading from 1.x to 2.x. When we’re ready to commit it to core, we’ll consider it at least beta stability (rather than alpha).
Once again, really fantastic work here.
Next

So there you have it. JSON API will not be shipping in Drupal 8.6 this fall.
The primary reason being that it’s preferred for significant new core features to land early in the release cycle, especially ones shipping as stable from the start. This also gives the Admin UI & JS Modernization Initiative more time to actually exercise many parts of JSON API’s capabilities, and in doing so validate that it’s sufficiently capable to power it.

For us as JSON API module maintainers, it keeps things easier for a little while longer: once it’s in core, it’ll be harder to iterate: more process, slower test runs, commits can only happen by core committers and not by JSON API maintainers. Ideally, we’d commit JSON API to Drupal core with zero remaining bugs and tasks, with only feature requests being left. Good news: we’re almost there already: most open issues are feature requests!

For you as JSON API users, not much changes. Just keep using https://www.drupal.org/project/jsonapi. The 2.x branch introduced some breaking changes to better comply with the JSON API spec, and also received a few new small features. But we worked hard to make sure that disruption is minimal (example 123).1
Use it, try to break it, report bugs. I’m confident you’ll have to try hard to find bugs … and yes, that’s a challenge to y’all!

If you want to stay on 1.x, you can — and it’s rock solid thanks to the test coverage we added. That’s the reason we waited so long to work on the 2.x branch: because we wanted the thousands of JSON API sites to be in the best state possible, not be left behind. Additionally, the comprehensive test coverage we added in 1.x guarantees we’re aware of even subtle BC breaks in 2.x! ↩︎

If you have been to any of the North American Drupal Camps, chances are you recognize Amber Matz. She is the production manager and a trainer at Drupalize.Me. Drupalize.Me is a site for Drupal tutorials and trainings. Amber, along with Joe Shindelar, travel to the various Drupal Camps and DrupalCons and currently run Drupal 8 Theming workshops.

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

During my DrupalCon Nashville keynote, I shared a brief video of Mike Lamb, the Senior Director of Architecture, Engineering & Development at Pfizer. Today, I wanted to share an extended version of my interview with Mike, where he explains why the development team at Pfizer has ingrained Open Source contribution into the way they work.

Mike had some really interesting and important things to share, including:

Why Pfizer has chosen to standardize all of its sites on Drupal (from 0:00 to 03:19). Proprietary software isn't a match.

Why Pfizer only works with agencies and vendors that contribute back to Drupal (from 03:19 to 06:25). Yes, you read that correctly; Pfizer requires that its agency partners contribute to Open Source!

Why Pfizer decided to contribute to the Drupal 8's Workflow Initiative, and what they have learned from working with the Drupal community (from 07:27 to 10:06).

How to convince a large organization (like Pfizer) to contribute back to Drupal (from 10:06 to 12:07).

Between Pfizer's direct contributions to Drupal (e.g. the Drupal 8 Workflow Initiative) and the mandate for its agency partners to contribute code back to Drupal, Pfizer's impact on the Drupal community is invaluable. It's measured in the millions of dollars per year. Just imagine what would happen to Drupal if ten other large organizations adopted Pfizer's contribution models?

Most organizations use Open Source, and don't think twice about it. However, we're starting to see more and more organizations not just use Open Source, but actively contribute to it. Open source offers organizations a completely different way of working, and fosters an innovation model that is not possible with proprietary solutions. Pfizer is a leading example of how organizations are starting to challenge the prevailing model and benefit from contributing to Open Source. Thanks for changing the status quo, Mike!

Gatsby is a really fast React-based static site generator. You can use it to create a static site, with content pulled from Drupal and other content management systems.

Why Use Gatsby?

Unlike dynamic sites which render pages on-demand, static site generators pre-generate all the pages of the website. This means no more live database querying and no more running through a template engine. Performance goes up and the maintenance cost goes down.

Static site generators have been evolving over the last few years. Tools like Jekyll, Gatsby, Hexo, Hugo become more and more popular. They have been chosen by developers who want a simple website/blog solution. They need very minimal server setup and have a low maintenance cost. However, static site generators usually require writing content in Markdown, which is not a great authoring experience for most content editors.

On the other hand, content management systems such as Drupal and Wordpress can provide a very powerful back-end. Having a WYSIWYG editor and content types help editors to manage content more easily and systematically. However, maintaining a CMS requires hosting a web server and database, and opens you up to security vulnerabilities and performance issues.

Gatsby stands in between the simplicity and robustness of static site, and the versatile back-end of a content management system. Using Gatsby means that you can host the CMS in-house and publish content generated by Gatsby as a static website. The first thing you’ll notice about Gatsby is how amazingly fast it is.

How to Integrate Drupal and Gatsby

In this tutorial, we are going to put together a demo that pulls Drupal content into a Gatsby site. We’ll borrow content of this awesome blog post to create a list of coffee types in Drupal, then transfer the list content to Gatsby.

This goal can be achieved with 4 steps:

Build a Drupal server

Build a Gatsby site

Fetch content from the Drupal server

Publish the Gatsby site

1. Build a Drupal server

Let’s say we already have a Drupal 8 site installed. We’ll need to:

Create a content type name Coffee with three fields: Title, Body and Image

At this step, we’ll be creating a new simple page /coffees that displays all the coffee types from the Drupal site.

Create the /coffees page

Create a new page in Gatsby is as simple as creating a new JS file. All Gatsby pages should be stored in /src/pages. In this case, we’ll create the file coffees.js in /src/pages and add the following code in coffees.js:

After adding the plugin configuration, the site should still be functioning. If Gatsby throws a 406 error, check the permission on the Drupal site; if Gatsby throws a 405 error, make sure module jsonapi_extras is enabled.

Build GraphQL to query all coffee nodes from Drupal

Gatsby comes with an in-browser tool for writing, validating and testing GraphQL queries named GraphiQL, and it can be found at localhost:[port]/___graphql, in our case it’s localhost:8000/___graphql

Let’s try querying all the Coffee nodes in this tutorial

After building the query successfully, let’s go back to the coffees.js file to execute the query.

Thanks to hot-reloading, we can see the sweet fruit of the work right after saving the file

So far, we have done:

Create an API server with Drupal and jsonapi, jsonapi_extras

Create a Gatsby site with page coffees.js that “reads” content from Drupal server

Let’s move the the last step of the tutorial: publish Gatsby site.

4. Publish the Gatsby Site

Gatsby names itself as a static static site generator, meaning its main purpose is to generate a bunch of static HTML, JS, CSS and images files. This action can be done by only one command:

gatsby build

Once finished, checkout /public folder to see result of your hard work along this long tutorial. Deploying your site is now simply copy/push contents in /public to server.

Conclusion

In this tutorial, we got to know how to:

Create a new Gatsby site

Install new plugin in Gatsby

Use GraphiQL to write, validate and test GraphQL query

I personally find that Gatsby is a good solution for setting up a simple blog. It’s easy to install, very fast, and requires zero server maintenance. In a future blog post, I’ll talk about how to integrate more complex data from Drupal into Gatsby.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Drupal is the leading enterprise web content management framework. With this popularity, of course, comes the increased risk to security. While Drupal in itself, out-of-the-box is widely considered to be very secure, there are additional methods that one must definitely undertake in order to ensure their Drupal site stays attack-proof as much as possible.
Minimum Administrative Privileges
In Drupal, users with administrative privileges have access to each and every section of the site. This, of course, means that administrative privileges in the wrong hands could prove to be the end of… READ MORE

One of the most useful items in the Drupal 8 toolbox is the Paragraphs Module. By creating custom paragraph types, you can have much finer control over the admin and content creation process in Drupal.

A recent client of ThinkShout needed a content type (office locations) to include ‘sub-pages’ for things like office hours, services, and other items depending on the location. Most of the sub-page content was pretty simple, but they also needed to have direct links, be printable, and have the same header as the parent page. This ruled out an Ajax solution.

We’ve been using Paragraphs to make configurable content throughout the site, and since the sub-pages only have Title and Content fields, we thought they would be a good fit here as well. We then decided to explore the possibility of using custom entity routes to fulfill the other requirements.

To start, we created two additional view modes for the sub-page paragraphs called Sub-page and Menu link containing the Content and Title fields respectively. By keeping these fields in separate view modes, we make it much easier to work with them.

Next we created a custom module to hold all of our code, ts_sub_pages. In addition to the standard module files, we added the file ts_sub_pages.routing.yml, which contains the following:

This defines a unique system path based on the parent node ID and the paragraph entity ID. It would look like https://example.org/node/12345/sub-page/321. It also defines the call to the controller and the title_callback, essentially a location where we can create functions to manipulate the entity and its route. The options define the things to pass into the controller and title callback functions, and we also define access permissions using requirements.

One of the odd things about the controller and title_callback calls is that they look like a path, but are not. They have a predefined (and minimally documented) structure. You must do the following to make them work:

Create two folders in your module: src/Controller (case is important).

Create a file called TSSubPagesController.php - this must match the call.

Here we have the namespace - this is our module. Note again that the src is taken for granted. Next are the Symfony/Drupal use statements, to pull in the classes/interfaces/traits we’ll need. Then we extend the ControllerBase class with TSSubPagesController, and define our subPageParagraph function. The function pulls in the $node and $paragraph options we defined in ts_sub_pages.routing.yml.

Now we can finally get to work on our sub-pages! Our goal here is to bring in the parent node header fields on every sub-page path. In the Drupal admin interface, go to ‘Manage Display’ for your content type. In our case it was /admin/structure/types/manage/location/display. Scroll to the bottom and under ‘Custom display settings’ you’ll find a link to ‘Manage view modes’. We added a mode called sub-page, and added all of the fields from our Location’s header.

Now we can bring that view of the node into the sub-page using the subPageParagraph function we defined above:

We get the node and paragraphs using getViewBuilder, then the view modes for each. The node’s ‘sub-page’ view mode contains all of the header fields for the node, and the paragraph ‘sub-page’ view mode contains the paragraph body. We return these, and the result is what looks like a page when we visit the base paragraph url of /node/12345/sub-page/321. The title is missing though, so we can add that with another small function inside the TSSubPagesController class (we call it using the _title_callback in ts_sub_pages.routing.yml):

Now we need to build a menu for our sub-pages. For this we can just use the ‘sub-pages’ paragraph field on the parent node. In the admin display, this field is how we add the sub-page paragraphs, but in the public-facing display, we use it to build the menu.

First, make sure you include it in the ‘default’ and ‘sub-page’ displays as a Rendered Entity, using the “Rendered as Entity” Formatter, which has widget configuration where you need to select the “Menu Link” view mode. When we set up the Paragraph, we put the Title field in the ‘Menu Link’ view. Now the field will display the titles of all the node’s sub-pages. To make them functional links, go to the ‘Menu Link’ view mode for your sub-page paragraph type, make the Title a ‘Linked Field’, and use the following widget configuration:

Next we need to account for the fact that the site uses URL aliases. A node called ‘main office’ will get a link such as /locations/main-office via the Pathauto module. We want our sub-pages to use that path.

We do this by adding a URL Alias to the sub-page routes on creation (insert) or edit (update). In our module, we add the following functions to the ts_sub_pages.module:

These get called every time we add or update the parent node. They call a custom function we define just below. It’s important to note that we have a custom title field field_title_text defined - your title may be the Drupal default:

This function gets the sub-page paragraph title, and creates a URL-friendly slug. It then loads the paragraph’s node, gets the current language, ID, and alias. We also build the system path of the sub-page, as that’s necessary for the url_alias table in the Drupal database. Finally, we check that there’s no existing path that matches ours, and add it. This will leave old URL aliases, so if someone had bookmarked a sub-page and the name changes, it will still go to the correct sub-page.

Now we can add the ‘Home’ link and indicate when a sub-page is active. For that we’ll use a custom twig template. The field.html.twig default file is the starting point, it’s located in core/themes/classy/templates/field/. Copy and rename it to your theme’s template directory. Based on the field name, this can be called field--field-sub-pages.html.twig.

Here, sub_text gets the sub-page title, and sub_path the path of each sub-page. We then check if the current url ends with the path, and if so, we add the active class and remove the link.

And that’s it! The client can now add as many custom sub-pages as they like. They’ll always pick up the parent node’s base path so they will be printable, direct links. They’ll have the same header as the parent node, and they will automatically be added or deleted from the node’s custom context-aware menu.

If you are just starting with Drupal 8 then one of the most important things you should know is to enable the debug mode and error reporting on Drupal 8. This is really important for backend as well as frontend developer to the full error on your screen while you are working because you might not know what is the exact issue with the site with just a generic error statement.

Filtering out invalid entity references in Drupal 8
mglaman
Fri, 07/06/2018 - 15:15
Today I was working on a custom Drupal 8 form where I needed an option to purge existing entities and their references on a parent entity before running an import. It seemed pretty straightforward until I saw "ghost" values persisting on the parent entity's inline entity form. Here's my journey down the rabbit hole to fix broken entity reference values.

Automated accessibility tools are only one part of ensuring a website is accessible, but it is a very simple part that can catch a lot of really easy to fix issues. Issues that when found and corrected early in the development cycle, can go a long way to ensuring they don’t get compounded into much larger issues down the track.

I’m sure we all agree that the accessibility of ALL websites is important. Testing for accessibility (a11y) shouldn’t be limited to Government services. It shouldn’t be something we need to convince non-government clients to set aside extra budget for. It certainly shouldn’t be left as a pre-launch checklist item that only gets the proper attention if the allocated budget and timeframe hasn’t been swallowed up by some other feature.

Testing each new component or feature against an a11y checker, as it’s being developed, takes a small amount of time. Especially when compared to the budget required to check and correct an entire website before launch -- for the very first time. Remembering to run such tests after a components initial development is one thing. Remembering to re-check later down the line when a few changes and possible regressions have gone through is another. Our brains can only do so much, so why not let the nice, clever computer help out?

NightwatchJS

NightwatchJS is going to be included in Drupal 8.6.x, with some great Drupal specific commands to make functional javascript testing in Drupal super easy. It's early days so the documentation is still being formed. But we don't have to wait for 8.6.x to start using Nightwatch, especially when we can test interactions against out living Styleguide rather than booting up Drupal.

We're pointing to our theme and custom modules as the source of our JS tests as we like to keep the tests close to the original JS. Our test settings are largely based on the Docker setup described below, with the addition of the 'filter' setting which searches the source for .js files inside a tests directory.

A test could be as simple as checking for an attribute, like the following example;

Which launches the Styleguides table component, waits a beat for the JS to initiate then checks that our td elements have the data-label that our JS added. Or is could be much more complex.

aXe: the Accessibility engine

aXe is a really nice tool for doing basic accessibility checks, and the Nightwatch Accessibility node module integrates aXe with Nightwatch so we can include accessibility testing within our functional JS tests without needing to write out the rules ourself. Even if you don't write any component specific tests with your Nightwatch setup, including this one accessibility test will give you basic coverage.

$ npm install nightwatch-accessibility

Then we edit our nightwatch.json file to include the custom_commands_path and custom_assertions_path;

Here we're configuring aXe core to check for wcag2a and wcag2aa, for anything inside the .kss-modifier__example selector of our Styleguide. Running this will check all of our components and tell us if it's found any accessibility issues. It'll also fail a build, so when hooked up with something like CircleCI, we know our Pull Requests will fail.

If we want to exclude a selector, instead of the .kss-modifier__example selector, we pass an include/exclude object { include: ['.kss-modifier__example'], exclude: ['.hljs'] }.

If you only add one test add one like this. Hopefully once you get started writing Nightwatch tests you'll see how easy it is and eventually add more :)

You can include the accessibility test within another functional test too, for example a modal component. You'll want to test it opens and closes ok, but once it's open it might have some accessibility issues that the overall check couldn't test for. So we want to re-run the accessibility assertion once it's open;

If you're not using docker or any CI tools and just want to test this stuff locally, there's a node module for adding the selenium-webdriver but I haven't tested it out with Nightwatch.

Don’t forget the manual checks!

There’s a lot more to accessibility testing than just these kinds of automated tests. A layer of manual testing will always be required to ensure a website is truly accessible. But automating the grunt work of running a checklist against a page is one very nice step towards an accessible internet.

Drupal Camp Asheville is next weekend! Join members of the Drupal community of all different skill levels and career paths for 3 days of science, trainings, sessions, and sprints.

Hook 42’s own Adam Bergstein will be sharing some insights on everybody’s favorite online Drupal testing environment, Simplytest.me. He recently took over ownership of the service, and we are excited to hear about where it is going next!

Along with helping organize the camp, our newest team member, Jonathan Daggerhart, will be leading an all day training on Drupal 8 Essentials.

Support the game designs and theoretical work of As If Productions. Written especially for roleplayers, GMs, game designers, artists and neophiles who are interested in experimental applications of narrative engineering.