Drupal Feeds

Using the Content API Adam Balsam Thu, 08/17/2017 - 13:41

Lightning 2.1.7 includes a new top-level component: Content API. Its purpose is to provide a very basic server-side framework for building decoupled apps using Lightning as a backend. It has no strong opinions about how the "front-end" of such an application is implemented -- out of the box, it merely provides tools to deliver Drupal entities according to the JSON API specification.

Generally speaking, you can interact with API anonymously in the same way that an anonymous user can interact with a standard Drupal site. So you can do things like get a single piece of content, or a list of content without authenticating. For other actions -- the kind that would normally require you to be logged in to Drupal -- you will need to provide an OAuth access token in the header of your request. Tokens are related to a Drupal user and an OAuth client, which is associated with any number of Drupal user roles. You can obtain a token by making a specific HTTP request for it.

Let's go through some common, generic, use cases. I'll use cURL in my example so that you can easily test them out for yourself.

Getting a list of content

The API endpoints generally follow the following pattern: "/jsonapi/{entity-type}/{bundle}". So if we wanted to get a list of Basic Page content, we could send a GET request to "/jsonapi/node/page":

curl --request GET \ --url https://example.com/jsonapi/node/page

Which would return something like this:

{ "data": [ { "type": "node--page", "id": "api_test-unpublished-page-content", "attributes": { "nid": 1, "uuid": "api_test-unpublished-page-content", "vid": 1, "langcode": "en", "status": false, "title": "Unpublished Page", "created": 1502985175, "changed": 1502985175, "promote": false, "sticky": false, "revision_timestamp": 1502985175, "revision_log": null, "revision_translation_affected": true, "default_langcode": true, "path": null, "body": { "value": "--TESTING--", "format": null, "summary": null } }, "relationships": { "type": { "data": { "type": "node_type--node_type", "id": "8bae5c5c-697d-4b8a-ab22-b72e895a3b24" }, "links": { "self": "https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/jsonapi/node/page/api_test-unpublished-page-content/relationships/type", "related": "https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/jsonapi/node/page/api_test-unpublished-page-content/type" } }, "uid": { "data": { "type": "user--user", "id": "4d7eb3c7-db6d-4a01-8b3d-7d706d314f87" }, "links": { "self": "https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/jsonapi/node/page/api_test-unpublished-page-content/relationships/uid", "related": "https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/jsonapi/node/page/api_test-unpublished-page-content/uid" } }, "revision_uid": { "data": { "type": "user--user", "id": "4d7eb3c7-db6d-4a01-8b3d-7d706d314f87" }, "links": { "self": "https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/jsonapi/node/page/api_test-unpublished-page-content/relationships/revision_uid", "related": "https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/jsonapi/node/page/api_test-unpublished-page-content/revision_uid" } }, "moderation_state": { "data": { "type": "moderation_state--moderation_state", "id": "1a5f02e6-3f14-46a7-a40c-65590c8729a9" }, "links": { "self": "https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/jsonapi/node/page/api_test-unpublished-page-content/relationships/moderation_state", "related": "https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/jsonapi/node/page/api_test-unpublished-page-content/moderation_state" } }, "scheduled_update": { "data": [ ] } }, "links": { "self": "https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/jsonapi/node/page/api_test-unpublished-page-content" } }, ...

That's pretty verbose. We could simplify the response by adding the "fields" parameter. In this example, we only want the "title" and "created" fields:

curl --request GET \  --url https://example.com/jsonapi/node/page\ ?fields[node--page]=title,created # Note that I'm using `[` and `]` here for clarity. These characters need to be # encoded with `%5B` and `%5D` respectively if you want to actually use these # examples.

Which would return something like this:

{ "data": [ { "type": "node--page", "id": "0bee8eb7-0f06-4986-9ca0-e340021a0af3", "attributes": { "title": "A Page", "created": 1502985175 }, "links": { "self": "https://{DOMAIN.COM}/jsonapi/node/page/0bee8eb7-0f06-4986-9ca0-e340021a0af3" } }, { "type": "node--page", "id": "4d7eb3c7-db6d-4a01-8b3d-7d706d314f87", "attributes": { "title": "Another Page", "created": 1502985175 }, ... Getting a specific piece of content

We can request a specific piece of content by specifying its UUID in the URL:

curl --request GET \  --url https://example.com/jsonapi/node/page/0bee8eb7-0f06-4986-9ca0-e340021a0af3

 Which would return something like this (but more verbose since we didn't use the "field" parameter):

{ "data": { "type": "node--page", "id": "0bee8eb7-0f06-4986-9ca0-e340021a0af3", "attributes": { "title": "A Page", "created": 1502985175 }, "links": { "self": "https://example.com/jsonapi/node/page/0bee8eb7-0f06-4986-9ca0-e340021a0af3" } }, "links": { "self": "https://example.com/jsonapi/node/page/0bee8eb7-0f06-4986-9ca0-e340021a0af3?fields%5Bnode--page%5D=title%2Ccreated" } } Getting a token

You will need to provide an access token for any request that anonymous users are not authorized to execute. Tokens are granted via the "/oauth/token" endpoint, and requests for a token must include a client_id, client_secret, username, and password. OAuth clients inherit the permissions of standard Drupal user roles by selecting one or more roles on the client's configuration form, under "Scopes". A typical setup would involve the following steps:

  1. Create a Drupal role ("/admin/access/roles") with the permissions you want the consuming app to be allowed to perform.
  2. Create a Drupal user ("/admin/people/create") that the API will use and assign that user the role you just created.
  3. Create an OAuth2 client ("/admin/config/people/simple_oauth/oauth2_client/add") and assign it the same role as the user you just created via the Scopes section.

Once that's done, you can use the following to obtain an access token, where:

  • CLIENT_ID = The OAuth2 client UUID, displayed after creation of the client in Step 3 at "/admin/access/clients"
  • SECRET = The "New Secret" you chose when creating the client  in Step 3
  • USERNAME = The Drupal username of the user you created in Step 2
  • PASSWORD = The password you gave the Drupal user in Step 2
curl -X POST -d \ "grant_type=password\ &client_id={CLIENT_ID}\ &client_secret={SECRET}\ &username={USERNAME} &password={PASSWORD}"\ https://example.com/oauth/token

Which should generate a response like this:

{ "token_type": "Bearer", "expires_in": 300, "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz...", "refresh_token": "def50200bdb9093a7a6cc837dhcd1..." }

If you want to give it a try without your own sandbox setup, Headless Lightning has a nightly build deployed to https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com with a client and user preconfigured. So you should be able to use the "/oauth/token" endpoint there to get a valid token to our sandbox if you're curious.

Give it a try! Copy and paste the following into a terminal window:

curl --request POST \ --data "grant_type=password\ &client_id=api_test-oauth2-client\ &client_secret=oursecret\ &username=api-test-user\ &password=admin"\ https://headlessnightlytfrimmmkug.devcloud.acquia-sites.com/oauth/token Using a token

Once you have a token, it's easy to get data that anonymous users aren't authorized to access. Just add an Authorize header to your request, like so (replacing {ACCESS_TOKEN} with the access_token value in the /oauth/token response):

--header 'authorization: Bearer {ACCESS_TOKEN}'

So let's say we wanted to get a specific piece of content just like the "Get a specific piece of content" example above. But in this case, the content is unpublished and therefore anonymous users won't be able to access it. Given that the token was acquired:

  1. For an OAuth client that has a scope with the "View unpublished content" permission
  2. For user account that has a role with the same permission

We can successfully make the same request for an unpublished piece of content if we include the token in an authorization header like this:

curl --request GET \ --header 'authorization: Bearer {ACCESS_TOKEN}'\ --url https://example.com/jsonapi/node/page/api_test-unpublished-page-content # Where `api_test-unpublished-page-content` is the UUID of some piece of # unpublished content

Note how this request is identical to the anonymous request above except that it:

  1. Requests a resource that requires authorization
  2. Includes an "authorization" header

Given the authorization header, Content API will authenticate the request and then authorize it (or not) based on the permissions of the associated client and user.

Creating content

You can create new content by sending a POST request to "jsonapi/{entity-type}/{bundle}". You'll need to include a specific Content-Type header, and most configurations will require Authorization as well since anonymous users usually can't create content. For example:

curl --request POST \ --data '{"data": {"type": "node--page","attributes": {"title": "Created via JSON API"}}}'\ --header 'Content-Type: application/vnd.api+json'\ --header 'authorization: Bearer {ACCESS_TOKEN}'\ --url https://example.com/jsonapi/node/page Content vs Configuration Entities

Drupal makes a distinction between Content and Configuration entities. Sometimes content entities are further distinguished as being renderable and/or bundle-able. Content API makes no such distinctions. If your API client/user have permission to interact with an entity, it can do so through the API. That means you can do things like add fields to a content type via the API, or edit a moderation state transition.

Headless Lightning

Everything described here can be done with Lightning. But if you're building a decoupled application, you might want to check out Headless Lightning, which has a few additional features (and a few features removed) which make it more suitable for decoupled applications.

Building web services with Drupal 7

A web service is a software system designed to support interoperable machine-to-machine interaction over a network. Web services is a well-defined way for two computers to communicate with each other over the internet. 

Drupal web services is always a good option for you

In Drupal, web service is being used to communicate with other web applications or mobile applications. Content can be shared and easily integrated with other applications as well. 

Why use web services in Drupal?

Web services are useful because they present us with an architecture where a resource on a site (an image, textual content, such as a node ID or block ID, a video or audio file) is given a unique identifier. 

Use cases 

For example, in Drupal, every node has an ID. Every file you upload to a Drupal site also has a unique path to it.

This is extremely useful since all applications share this common semantic standard. We name things similarly on all of our web applications. 

Drupal services and real world examples

Here are some examples, perhaps we have to build a product site and they are developing a app for that product site in mobile, then we can pass data from web to mobile app using the web service.  For example if the HR Department wants to integrate its job postings and applications with another web application such as job portals, web services can make this happen.

Advantages of Drupal web development services you can’t ignore

This leads to another advantage of using web services with Drupal and why we would choose to use Drupal in the first place. Instead of having to upload our photos twice—once to our Drupal site and then repeating the procedure to our some other applications, services allows us to upload the images to our Drupal site once and then automatically send that data over to other application which wants without having to upload one (or even a batch of images) again. It saves us time and speeds up the entire process of generating web-based content.

Building web services for Drupal 7

Drupal can use web services following any of the protocols mentioned earlier, including XML-RPC, REST, and SOAP. Drupal can consume web services by requesting data from other web applications using RSS and XML-formatted requests. As a Drupal developer, you can write your own service code in Drupal using PHP. You can also use the Services module as well as other service-specific contributed modules to create these web service requests.

Service module supports multiple interfaces like REST, XMLRPC, JSON, JSON-RPC, SOAP, AMF and more.

Make use of Drupal Services module for:

  • Integration with core Drupal functionality like files, nodes, taxonomy, users, files and more.
  • Response format API allows you to define response Formats for CONTENT-TYPE ie. application/json or application/xml. (also calls such as ENDPOINT/node/1.json work)

Additionally, all the communication between services, in our example between a client and a server, happens over HTTP (the standard web protocol). This is a uniform protocol that is used for transport and communication of the service. All transports take place uniformly using GET, POST, PUT, and DELETE requests, for example.

The HTTP requests are stand alone and occurs at one given moment and is isolated from all other activated requests. If HTTP requests works and gets a response, it succeeds. If HTTP requests doesn’t get response from the server or application it's communicating with, it fails. The requests can be repeated an infinite number of times.
 

admin Fri, 08/18/2017 - 08:52 Drupal Drupal Development Drupal developer Drupal Application Development

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.
 

Direct .mp3 file download.

Ryan Price and Mike Anello discuss the pros and cons of the Paragraphs module, including using it for layout and/or information architecture. Ryan takes the discussion in unexpected directions by bringing up Pattern Lab as a prototyping tool and his mysterious "Ace in the Hole" (which Mike feels is more like a Jack of spades). In addition, there's some discussion about a new-ish feature in the Migrate Plus module that is sure to make migration developers happy.

Interview News DrupalEasy News Sponsors Upcoming Events Follow us on Twitter Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

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.

Direct .mp3 file download.

Ryan Price and Mike Anello discuss the pros and cons of the Paragraphs module, including using it for layout and/or information architecture. Ryan takes the discussion in unexpected directions by bringing up Pattern Lab as a prototyping tool and his mysterious "Ace in the Hole" (which Mike feels is more like a Jack of spades). In addition, there's some discussion about a new-ish feature in the Migrate Plus module that is sure to make migration developers happy.

Interview News DrupalEasy News Sponsors Upcoming Events Follow us on Twitter Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

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.

With the introduction of Drupal 8, the Drupal project introduced a bit of a paradigm shift for managing configuration for Drupal sites, moving toward encapsulating configuration separately from content, and providing a mechanism to manage configuration changes more effectively through Configuration Manager, which is a Drupal Core module.  Configuration Manager provides a mechanism for importing, exporting and synchronizing a site’s configuration components, which is great when you want to maintain a consistent configuration across different development environments.
Celebrating the 8.x-1.0 release of our configuration management helper modules.

One year ago we released the first public version of Config Split with the goal to simplify working with Drupal cores configuration management. The main motivation was to find a solution for having development modules in local environments and avoiding to deploy their configuration. To achieve this in the cleanest way possible we decided to interact with Drupal only during the configuration import and export operations by altering what is read from and written to the \Drupal\Core\Config\StorageInterface.

We quickly realized that this is a powerful way to interact with how Drupal sees the configuration to import and so we split off the code that does the heavy lifting into its own module and now Config Ignore and Config Role Split use the same mechanism to do their thing.

Config Split now has documentation pages you are welcome to contribute to and there will be a session at DrupalCon in Vienna in which I will show how it can be used to manage a sites configuration in interesting ways.

If you were an early adopter (pre beta3) but have not updated to a recent version, you will need to install Config Filter first or patch core. The workaround and legacy code has now been removed and the current code is going to be backwards compatible in the future. So if you use the APC class loader, make sure to clear the apc/apcu cache or you might get an error after updating.

Tags: Drupal 8Drupal PlanetDrupalConConfiguration Management

This week, I spoke with Chris Shattuck (chrisshattuck), who has been part of the Drupal community for 10 years, and has attended 7 DrupalCons.

Properly linking to pages with dynamic routes can be tricky. Here's how to do it properly.

GovHack is an annual hackathon that runs in Australia and New Zealand, where participants have 46 hours to create innovative new products using the open data published by government bodies. It started in 2007 with a single event held in Canberra, and has now grown to more than 40 locations and 3,000 participants.

Acquia was thrilled to provide support to GovHack for a 2nd year in 2017.

Tags: acquia drupal planet
Share:

Browsing through the interweb I happened across this bold statement a few weeks ago. A statement so bold, it inspired me to write a blog post in response.

by irma.kelly / 22 August 2017

Scrum Masters being co-located with their teams, sure it is the best and most favourable scenario for teams working on complex projects, but to go as far as to say that Scrum Masters are ONLY effective in this instance - nope. Sorry, I have to graciously disagree.

Obviously there are different challenges that come with facilitating Agile ceremonies and interacting with the team remotely as opposed to face-to-face. A completely different approach needs to be taken on my behalf to keep the team engine purring away.

Personally for me, the “different approach” I take with managing remote teams, as opposed to co-located teams is to ensure uber transparency and over-communication on my part in regards to the all of the work that the team currently have in-flight. On my part this includes:

  • Ensuring that work in flight includes “Acceptance Criteria” and a “Definition of Done” agreed to by both the team and the client. This ensures that both the client and the team have an agreed vision of the product we are building. More importantly, it removes the need to make assumptions about a solution on both sides

  • The use of an online and up-to-date Kanban board that both the client and the team can freely access

  • Complete honesty with the client and the team in regards to all aspects of the project. Especially during the trickier and stressful moments of project delivery. If something is starting to go pear shaped, call it out early - don’t hide it!​

There are a plethora of tools now available that help enable remote collaboration. I thought it might be worthwhile sharing some of the tools that the teams at PNX use to make remote collaboration simpler.

Slack / Go To Meetings / Google Hangouts

With a large percentage of our internal staff located across Australia, these are PNX’s go-to tools for remote collaboration. We utilise both GoToMeeting and Google Hangouts (depending on individual client preferences) as tools to enable our daily stand-ups with our clients. Daily stand-ups and the ability to quickly ask via a hangout or GoToMeeting has drastically reduced the amount of email correspondence between PNX and our clients. The result? A reduction in idle time, as questions can be answered relatively quickly instead of waiting for a reply via email.

Access to an online Kanban board

The ultimate in uber transparency. There is nothing more satisfying for an Agile Delivery Manager than to see tickets move to the right of the board. Likewise for our clients! Each ticket on the board details who the work is assigned to and the status of the task. At a glance, anyone with access to the project kanban board can see the status of work for a given sprint.

Google Sheets - My favourite go-to tool, when it comes to interactive Agile ceremonies

The most common question I’m asked about working with remote teams is “how do you facilitate an Agile ceremony like a Retrospective with a remote team?” My favourite go-to tool for this is Google Sheets. Before each retro, I spend a half hour putting the retro board together on a Sheet. I try and mix it up every retro as well, using different Retro techniques to keep things interesting.  I mark defined spaces on the sheet where comments are to go, and I share the sheet with the team. Facilitating the Retrospective via a video conference (if possible), I timebox the retro using a timer app shared on my desktop. The team then fill in the Google Sheet in real time. The virtual equivalent of walking up to a physical board, and placing a post-it up there! I have replaced all of the original text captured during the retro with lorem ipsum text. What's said in retro - stays in retro! We had a little fun with the below retro as you can see!

For sensitive conversations - A video conference (or the phone)

The tools above are handy for enabling remote collaboration but for sensitive conversations with a colleague or client in a remote location, a video conference (where you can see each other) is a must. Sensitive conversations are fraught with danger via chat or email and a neutral tone is difficult to convey when we’re in the thick of things. If a video conference is not possible, though, simply pick up the phone.

I’d love to hear about some of the tools you use with your team to enable remote working. What are your recommended tools of choice?

Tagged Remote Working

Posted by irma.kelly
Agile Delivery Manager

Dated 22 August 2017

Add new comment
At AGILEDROP, we like to share our knowledge and experience with others. Our development director Bostjan Kovac did that at DrupalHeart Camp Zagreb with his session Web Accessibility in Drupal 8. We will look at this session and we will present it in two parts. This is the first part. The inspiration for his session (and of course this blog post) came from the fact that web accessibility was a demand when Bostjan worked on a couple of projects. He also went to one of the similar sessions on Drupal Camp in Vienna 2015 and decided to take a closer look at it. Today Drupal websites sites have… READ MORE
POWDR’s Front End Architecture Build POWDR’s Front End Architecture Build root Fri, 08/25/2017 - 11:31

Powdr Resorts is one of the largest ski operators in North America. Since December, we've spun up nearly a dozen decoupled Drupal website for the holding company including websites for Boreal Mountain Resort, Copper Mountain, Camp Woodward, and more. 

The work was completed with our frontend partners at Hoorooh Digital and hosting partners at Acquia. It is cutting edge and worth diving into so we've put together an eBook style review of the project's parts. 

In prior posts, we've covered Hosting a Decoupled Drupal Site, Decoupled Drupal: A 10,000 ft View, and Decoupled Drupal Technologies and Techniques

In the final installment of our decoupled Drupal series our partner, Denny Cunningham, Lead Front End Developer at Hoorooh Digital, discusses the three main areas that needed to be addressed during the build of POWDR’s front end architecture: Routing & Syncing with the API, Component Driven Content, and the Build Process & Tools. Read the whole piece on Acquia's developer center, here

In order to respond to both site builder and developer feedback about core experimental modules in Drupal 8, the committer team is proposing the following changes starting with the Drupal 8.5.x branch (which is now open for development):

  1. Experimental modules that have alpha stability will only be committed to development branches of Drupal 8.
  2. If an experimental module has not achieved at least beta-level stability by the alpha1 release of the branch itself, its development will move to the next development branch and the module will not be included in the branch's alpha release. (Or, alternately, the module may be removed from core if there's no clear path to stability.)
  3. Once an experimental module reaches beta stability, we now require (a) upgrade paths, and (b) backwards compatibility (or a deprecated BC layer) for any API improvements.

For example, if an initiative team wanted to add a new experimental module to core for their desired feature, they could introduce a patch that met the requirements for an experimental module and it could be committed to 8.5.x as an alpha-stability experimental module. However, by 8.5.0-alpha1 (the week of January 17, 2018), either the module would need to be in "beta" level stability (which means its API and data model would be considered stable, with upgrade paths and API BC layers provided when needed), or it would be left in the 8.6.x branch, but removed from the 8.5.x branch before tagging the alpha. 8.5.0 would ship without this new functionality, but (if completed in time) it could be available in the 8.6.0 release.

These policy changes are intended to address a number of frustrations with the existing experimental module process and to better meet expectations for non-core site builders and developers.

For background on this decision or to provide your feedback, see the core policy issue that discusses this proposed change. The issue is open for community feedback until September 6, 2017. Thank you in advance!

Views has a setting to exclude the current nid from the URL from the listing one is currently viewing. This is essential when you have, say, a list of related nodes that are are defined by a category that includes the current node. If you don't exclude the current node, your current node will be listed in the "related content" block on itself. Well, obviously one is related to oneself, one thinks.

First, I tired to accomplish this through the UI with these steps, below.

GSoC 2017 | Week 12: Port Vote Up/Down sudhanshu Sat, 08/26/2017 - 03:44

Sometimes you might want to display additional data in the autocomplete results, for instance add content language next to the title, or display entity type or any other related data. In this blog post I will demonstrate how to alter suggestions in autocomplete fields in Drupal 8. The project is available for download from github, see the link at the bottom of the page.

Here is the module structure I will be using:

Accessibility in Drupal 8 brandt Mon, 08/28/2017 - 15:12 Michael Dickey Aug 29, 2017

Can you see the Drupal 8 logo above? Accessibility standards could help make this image equally useful to all users.

In this post we will cover...
  • What accessibility is
  • Why accessibility is important
  • What improvements Drupal 8 has made around accessibility
  • What Palantir does to make sure our sites are accessible

We want to make your project a success.

Let's Chat.

My first real experience with web accessibility came when I joined the federal government as a developer during the executive branch’s broad adoption of Drupal. Until that point, I’d been working on smaller projects for my own company and several other clients. While I was familiar with alt text and design concepts dealing with contrast, my knowledge of accessibility didn’t extend very far beyond that.

If I’m being completely honest, I’m embarrassed to say that I hadn’t really put much time into thinking about how users with disabilities interacted with the sites I was creating. My thoughts (and many late nights) largely centered around learning as much as I could that would help me solve my immediate business needs. What I didn’t realize was that my ignorance was not only hurting my business, but I was missing a vitally important piece of development knowledge.

What is Accessibility?

Generally speaking, accessibility refers to ensuring that people with disabilities have the same access (both physical and virtual) as others. Everyone is familiar with the benefits of providing physical improvements like ramps to building entrances and at sidewalk crossings, expanding hallways, requiring elevator doors to remain open for a certain period of time, and adding raised surfaces near the rails on metro and subway platforms. Web accessibility refers specifically to similar best practices put to use for a more inclusive environment online.

Many people generally think of screen readers and visual disabilities when it comes to accessibility, but the range of topics that it covers is larger than that and includes more than just disabilities. For example, needing sufficient contrast so someone can see a site on their phone on a sunny day. That's an accessibility use case for sighted users just as much as it is for someone with deteriorated vision. Similarly, the ability to pause autoplay videos is an accessibility feature for those with neurological issues, but is also a feature for anyone that gets motion sickness.

There are guidelines provided as a goalpost to achieving appropriate levels of accessibility that are a great resource for anyone looking to ensure that their site is as useful as possible to as broad an audience as possible. WCAG 2.0 (you may have heard it called “wick-ag”) is generally accepted as the standard to measure against when talking about information you’re presenting to users on a website.

These were developed by the World Wide Web Consortium or W3C and published in 1999 as version 1.0 with 2.0 being published in 2008. The federal government began using WCAG 2.0 in measuring compliance with their requirements, known as 508 or Section 508, in early 2017, though several agencies have been using them as a reference point for years. Section 508 is an amendment to the Rehabilitation Act of 1973 that was passed as the version we know today in 1998. Interestingly, it was originally passed in 1986 showing a lot of forward thinking by the government, but it lacked enforceability. I have had the pleasure of working with many government employees that feel strongly about and take to heart the spirit of 508 compliance. It’s an attitude that I have carried with me beyond my time with them.

In addition to the above, individual companies often have a set of guidelines that address accessibility for their sites as well. W3C has also published several other standards and guidelines that focus on various aspects of online interaction to include Authoring Tools (ATAG), web browsers and media players (UAAG), and Accessible Rich Internet Applications (ARIA) which I’ll touch upon again later.

Why Bother?

Many times people find themselves in a position where they need to defend the need for adopting accessibility standards. This can be a result of various factors including budget (just trying to get an MVP out), perceived lack of time, lack of knowledge/not recognizing it as even being something to think about, or difficulties around training editorial staff and content creators. If you find yourself in that position, here are a few points to help people understand the importance of addressing web accessibility.

Disabilities affect users’ capacity to interact with your site in many ways. This can include visual, mobility, auditory, cognitive or intellectual and neurological impacts. According to 2010 U.S. Census data, 19% of the population has a disability. That is a lot of people to be ignoring if you’re not willing to discuss ways of improving accessibility at your organization. It’s unclear exactly how many of that 19% have disabilities that directly impact interaction with a website (i.e., a mobility disability affecting the foot may not have an impact), but with that percentage equaling 57 million people, it is safe to assume that there are more people with disabilities using your site than you might initially think.

What is also not included in Census data is those disabilities that are temporary. For example, a user with a broken hand in a cast will have difficulty on a site that requires use of a mouse. There are a number of tools your users may be implementing when they come to your site including screen readers, braille terminals, screen magnifiers, speech recognition software, keyboard overlays and keyboard shortcuts. If ignored, your site may respond in unintended ways when visited by a user implementing one of those tools.

An added benefit to addressing accessibility comes in the way of SEO (search engine optimization). Many of the best practices around developing for accessibility have a direct correlation to best practices of developing for SEO. Things like semantic markup and site maps are used by some of the assistive technologies mentioned above. Having them present allows for search engines to use that same information to better index your site which improves your chances of achieving favorable rankings in searches. It is my personal belief that there will come a time that search engines will penalize sites for not being accessible in a similar manner to recent decisions around mobile and use of SSL certificates (https).

A negative impact of not addressing accessibility that I’ll touch on briefly has to do with legal ramifications. If you’re running a government site or receiving significant government funding, there is the aforementioned 508 compliance, but what about those in the private sector? The Americans with Disabilities Act has recently been cited in lawsuits claiming that users’ rights were violated based on the fact that “No individual shall be discriminated against on the basis of disability in the full and equal enjoyment of the goods, services, facilities, privileges, advantages, or accommodations of any place of public accommodation by any person who owns, leases (or leases to) or operates a place of public accommodation.” For any site that can be proven to be a “place of public accommodation” this should be given serious consideration.

Lastly, the reason for worrying about accessibility is that it’s the right thing to do. As site owners, designers and developers it is our responsibility to make the web a better place. For the internet to have sites on it that exclude certain visitors is contrary to its purpose. I find (as someone that does not have a disability affecting my use of the internet) it can sometimes be difficult to keep this at the top of my mind. This is why I suggest thinking of it from the point of view of being with a loved one, sibling, or child with a disability while they interact with your site and imagine what sort of experience you would want them to have.

Drupal 8 and Accessibility

Drupal 8 has made some significant improvements around accessibility to ensure that your site starts with a strong foundation. I’ll list some of them here.

Required Alt Text

Alt, or alternative, text refers to the words used to tell users what is in the content of an image. It’s usually not rendered in the display of the page, but used by tools like screen readers. This is set to required by default in D8. Even having it set to required still does not remove the need for proper training of your content creators to ensure that the text provided is an appropriate description of the image taking into account its intended purpose and not just a word or two to satisfy the required field. A great presentation on alt text for further reference can be found at https://www.slideshare.net/whitneyq/writing-great-alt-text-38937551.

Semantic Elements

Divs and spans are generic HTML tags used to define elements on a page. Historically they’ve been used to define most every element with the exception of things like images which have had their own tag. In HTML5, semantic elements allow developers to assign a name that fits the purpose of a particular element, and Drupal 8 has taken advantage of this providing a common element name for users and machines to know what to expect when presented.

Instead of one developer assigning a class of “nav” to a navigation div and another assigning an id of “navigation,” use of semantic elements allow for “nav” to replace div or span. That way a screen reader can know to present this to the user in a way that makes sense instead of it sounding like a part of the content. Some other element names include , , and , and . This is a great example of when SEO overlaps with accessibility because search engine crawlers will also use these same element names to understand your pages.

WAI-ARIA

Another W3C published set of standards, WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) deals with making certain types of content available to all users. Drag and drop functionality is a great example of this. Drupal 8 has followed WAI-ARIA guidance to make these more understandable to assistive technologies.

Aural Alerts

A JavaScript method (Drupal.announce) in D8 takes advantage of the above ARIA compliance and presents screen readers with a string to be read aloud to the user. To understand the need for this it is helpful to understand that a screen reader is only “looking” at one part of a page at a time, so if a change happens on the page that a user would be expected to see, the screen reader would typically be unaware of it. This allows for changes happening on the page to be made known to a user using a screen reader.

Constrained Tabbing

Various users may use the tab key on their keyboard to move around on your website’s page instead of using a mouse. Drupal 8 introduced another JavaScript feature called tabbing manager that allows for control over where the user can tab into. Think of this in context by imagining how tabbing would work when there is an overlay on the page if it wasn’t constrained to within the overlay.

Form Errors

In Drupal 8 there is an option to turn on a feature to improve accessibility related to the display of form errors. By default form errors are presented after submission at the top of the form with fields that failed validation highlighted in red. To understand the difficulty this presents, it is important to think of a screen reader that can only present what is on the screen in the order presented without contextual knowledge. In that case the user will get the error (e.g., “This field does not allow any special characters”) without knowledge of which field is being referred to, as the screen reader will not announce that the offending field is highlighted.

Colorblind users could also miss the highlighting of the field. You can, and should, use better form validation error verbiage to help with this, but putting the error inline with the field it relates to helps to provide context. There were a number of issues with this feature when D8 was released initially, but most of these have been worked out (including all of the “must have” issues) so please do some research to determine where it stands at the time you consider implementing it. To see if there are any issues still remaining that could affect your decision you can follow the issue at drupal.org.

CSS Display Options

Work has gone into reducing the use of “display:none;” in Drupal 8 as its use hides content from screen readers. Reasons for not using “display:none;” can be hard to guess with the usual response being “if I’m hiding content from rendering, why would I care if a screen reader can find it?”

This becomes problematic when content is hidden for treatments like accordions where a user accessing your site with a screen reader would have no way of knowing the content existed. To help with this, D8 has adopted four new display classes: (1) hidden, (2) visually-hidden, (3) visually-hidden.focusable and (4) invisible, and each have specific behaviors related to hiding an element visually as well as from screen readers.

For all of these reasons and more, using D8 in your project should provide you with a great starting point to build a site that benefits all users equally. Accessibility has clearly been given a lot of attention. Keep in mind that as with any starting point, it will still be possible for missteps and shortcuts to be taken that can reduce your site’s accessibility over time, so diligence is required.

Palantir and Accessibility

Palantir has been building accessible websites since the standard was introduced. For the majority of our clients, WCAG 2.0 level AA compliance is contractually obligated. Our automated and manual testing tools adhere to the WCAG 2.0 level AA standard, which is what our best practices and heuristic evaluations of design also follow.

We employ many of the tools, practices, and techniques documented in The A11y Project in order to design and build accessible products for our clients. Most of these tools and techniques are based on the WCAG 2.0 level AA standard (at a minimum). We ensure that the code we develop adheres to accessibility standards by employing a three-tiered approach to accessibility assurance:

1.) Following best practices in accessible design through:

  • Heuristic consciousness of accessibility in design, including (but not limited to):
    • Selecting colors for text that have a high contrast ratio with the background
    • Styling interactive elements, such as links, using a variety of indicators rather than relying on color alone
    • Including notifications and feedback for interactions such as an error message, or a success confirmation
    • Designing large links, buttons, and controls
    • Creating unambiguous and consistent navigation options
    • Composing clear layouts with organized content
  • Chrome accessibility extensions
    • Chrome Accessibility Developer Tools
    • Color Contrast Analyzer
    • WAVE toolbar in Firefox

2.) Performing automated, continuous code testing to identify any accessibility issues in the front-end code

3.) Testing individual, rendered pages of the final product using Tenon, which can assess that the code and content entered in the CMS are producing rendered pages that ultimately meet accessibility standards (upon client approval and on a project-by-project basis)

  • There is a Drupal module for Tenon that can be used, though it requires the client to create an account with Tenon that has a monthly cost based on the number of API calls made from the client site to Tenon
  • There is also a WordPress plugin for Tenon as well, which also requires a paid Tenon account
What Can You Do?

There are a lot of ways that you can help to ensure your organization’s success in terms of making your online resources accessible. The first is in the performance of an audit to determine where things stand currently. There are a lot of tools available for this and many of them are free to use. Tenon, WAVE, HERA, and W3C’s Validator are some. Running these will return a lot of feedback and issues. Do not get overwhelmed and throw up your hands. Compile them into a single spreadsheet or tracker and start prioritizing them based on what is achievable given your current resources (example).

A single audit is also not going to be enough to ensure your site is accessible. Over time, as new code is added and content creators add content, things can change. Regularly scheduled audits will help you surface any issues. There are also services that will connect you with groups of users with a variety of disabilities that can test your site for you.

Content creators are responsible for a lot of the work it takes to keep your site compliant. Drupal does a great job of creating a solid foundation, but if training isn’t provided to content creators there will still be issues. An example of this is providing poor alt text even if it’s required as mentioned above. Another area that is often overlooked is proper use of heading order. Proper use and nesting of heading tags (e.g., , , etc.) will allow for users to better understand the organization of content on a page. For more information on this you can reference W3C’s guidance.

Another way to help is to simply speak up. Remediation of issues is always more difficult than including accessibility from the start of a project. During planning and design be the voice that keeps accessibility on the table. Ask questions when new functionality or design elements are introduced. You may be the only one asking these questions at first, but you will find that over time it will become engrained in others as well so that accessibility planning is not an afterthought, but simply part of the process. Compliance to accessibility standards and best practices doesn’t require a lot of additional technology or even skill. It just needs attention.

Conclusion

Hopefully this has helped you gain a better understanding of web accessibility, why it matters, and why Drupal 8 accessibility improvements will help you create sites that are equally useful to all users. This has certainly not been a comprehensive deep dive into the topic, but it is meant to provide you with enough knowledge to feel comfortable bringing accessibility up in conversations at your next planning meeting or to get you thinking about it while you build your next module.

Please contact us to discuss how Palantir can help you use Drupal 8 to improve accessibility on your next project.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

The Geolocation Field Module allows us to store geographical locations (e.g. addresses) as value pairs (latitude, longitude). These values can be rendered in a map with the help of a map marker.

Many map markers in a map are useful in a wide variety of cases, for example to show graphically different offices of a bank in a city or to show the cities/countries of a concert tour of your favorite band. The possibilities are endless.

In this tutorial we are going to learn how to show the markers in a map of four tourist Attractions in New York City using the Geolocation Field Module and Views.

Putting this here because I didn’t see it mentioned elsewhere and it might be useful for others. Thinking about the history of the Islandora solution packs for different media types, the Basic Image Solution Pack was probably the first one written. Displaying a JPEG image, after all, is — well — pretty basic. I’m working on an Islandora project where I wanted to add a viewer to Basic Image objects, but I found that the solution pack code didn’t use them. Fortunately, Drupal has some nice ways for me to intercede to add that capability!

Step 1: Alter the /admin/islandora/solution_pack_config/basic_image form
The first step is to alter the solution pack admin form to add the Viewers panel. Drupal gives me a nice way to alter forms with hook_form_FORM_ID_alter().

/** * Implements hook_form_FORM_ID_alter(). * * Add a viewers panel to the basic image solution pack admin page */function islandora_ia_viewers_form_islandora_basic_image_admin_alter(&$form, &$form_state, $form_id) { module_load_include('inc', 'islandora', 'includes/solution_packs'); $form += islandora_viewers_form('islandora_image_viewers', 'image/jpeg', 'islandora:sp_basic_image');}

Step 2: Insert ourselves into the theme preprocess flow
The second step is a little trickier, and I’m not entirely sure it is legal. We’re going to set a basic image preprocess hook and in it override the contents of $variables['islandora_content']. We need to do this because that is where the viewer sets its output.

/** * Implements hook_preprocess_HOOK(&$variables) * * Inject ourselves into the islandora_basic_image theme preprocess flow. */function islandora_ia_viewers_preprocess_islandora_basic_image(array &$variables) { $islandora_object = $variables['islandora_object']; module_load_include('inc', 'islandora', 'includes/solution_packs'); $params = array(); $viewer = islandora_get_viewer($params, 'islandora_image_viewers', $islandora_object); if ($viewer) { $variables['islandora_content'] = $viewer; }}

I have a sneaking suspicion that the hooks are called in alphabetical order, and since islandora_ia_viewers comes after islandora_basic_image it all works out. (We need our function to be called after the Solution Pack’s preprocess function so our 'islandora_content' value is the one that is ultimately passed to the theming function. Still, it works!

Pages