Feeds

Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Nov 18 2020
Nov 18

Have you ever wanted to exclude a block on just one content type? You would think that the existing block visibility plugin for "Content types: [x]" plus the "Negate this condition" would do it; however, what you quickly learn is that the plugin also returns false for non-node pages altogether! So, for example, when you say "show on NOT article" for example, it really evaluates to "show only on node pages that are not articles."

What we need to do is write a custom Condition plugin which has some more expansive logic, so we get what we want--"show on every page EXCEPT if that's a node page of bundle article."

To do this, we first need a custom module. For small things like this, I usually scaffold out a small module called "tweaks" using Drupal Console. In there, you need to create a Condition Plugin (inherits ConditionPluginBase), so create a folder called /src/Plugin/Condition, and in it put a NotNodeType.php with the code from the gist below!

https://gist.github.com/chrisfromredfin/d5b583c30129ac6f98d9687768eb2734.js

Sep 18 2020
Sep 18

Accessibility isn’t just a concern for web developers. With content being dynamically created, there are a few points content editors can keep in mind to make sure their content is accessible to everyone. Following accessibility standards helps non-visual users, but can also help all users find and understand the information they’re looking for.

Creating Emphasis

One of the most common times accessibility issues pop up is when content editors are trying to emphasize sections of text. It is important to keep in mind that screen readers do not recognize details like different colors or bolded text, but will intonate exclamation points. If it is vital to the understanding of the content that a certain sentence be highlighted, consider using an exclamation point. If it is not vital but may help visual users to better understand the message, your best bet is making use of bold. 

From a usability standpoint, be wary of using color for emphasis. Colors can have unintended implications, such as causing the user to think the text is a warning, or even a link. Text also has to pass a certain color contrast ratio with its background to maintain accessibility, so unless a designer or developer with a knowledge of accessibility has picked out new colors for you, it’s best not to introduce more.

Another common mistake when emphasizing content is using all uppercase letters. A screen reader will read this out like an acronym, which could be particularly painful for a full sentence. Aside from screen readers, it is also shown to be less readable for all users when there are more than one or two words in a row in all-caps. Sometimes you’ll see all-caps used on buttons or labels, but the crucial difference is that these are (or should be) made into all-caps with code. A screen reader will usually ignore the css and see the text as it is originally written.

Is bold not enough variation for your content? Talk to your designer or developer about coming up with additional text styles for you to use. You may think to yourself, “I already have a dropdown with five different text styles I can use!” What you’re probably referring to is the heading selector.

Heading selector in a WYSIWYG field in Drupal.

Headings should never be used for emphasis or a stylistic choice. They are a tool to add structure to a page.

Heading Structure

Headings are pieces of HTML that are used to give structure to a page. They make it possible for non-visual users to navigate and understand a page without needing to see visual indicators. There is a specific way headings need to be arranged on a page. 

Headings are nested, just like you would see in an outline of a paper where subsections are indented and have a different bullet point or character. Heading 1 is the topmost level, functioning as the title of the page. There should only ever be one H1 on a page, and if you’re using Drupal or any other content management system, the H1 is probably already generated for you as the page title. If you’re working in a body field, for example, you’ll most likely start with H2 to title a section of content. Anything else at this same section level will also be an H2. If you need to label sections within this section, you can start to use H3’s. If you need to go any deeper than this, you can start to use H4’s, H5’s, and H6’s, but if you are going this deep into the structure, it may become difficult to follow for your average user. Here’s an example of heading structure:

(H1) The Most Amazing Chocolate Cake

          (H2) My Grandmother’s History

          (H2) Ingredients

                    (H3) Types of flour you can use

                    (H3)  Alternative ingredients

                              (H4) Vegan alternatives

                              (H4) Gluten free alternatives

          (H2) Instructions

                    (H3) The cake

                    (H3) The frosting

An important thing to watch out for is that heading levels don’t skip. You don’t want to go from an H2 right to an H4. That makes it more difficult for non-visual users to understand the structure of the page, and creates inconsistencies for all users. If you keep finding yourself tempted to do this for visual reasons, think about why it feels like the heading style available doesn’t fit, and work with your designer to figure out how best to fix it.

As mentioned before, don’t use headings simply to emphasize text. If you’re making a whole sentence into a heading, it’s probably not the right use. Headings are also not designed to be used for long sections of text. Bigger and bolder does not always mean easier to read. Sometimes a pull quote or a custom text style is an option that will accomplish what you’re looking for, without creating accessibility and usability issues, as well as design inconsistencies between different content editors.

Foreign Languages

Sometimes on your site you’ll need to add text in a different language. Visual users can identify when they won’t be able to read something, but screen readers need a hint that a sentence is in a different language. There’s a simple way to add this hint to your text: the language button. When you add content to a text field, usually you will have a toolbar at the top that allows you to make things bold, add a link, etc. One button that you may see if you’re using Drupal looks like this:

Language button on a WYSIWYG field in Drupal.

If you see this button, you can highlight your text and select from the dropdown. If you don’t see this button, or any buttons, ask your developer to make it available for that field.

Another thing to note with foreign languages is that users can use external tools to translate the content into a language they understand. For this reason, it is best to stay away from made up words that would only make sense in the language you’re writing, but not others (i.e. “hangry”).

Special Characters

One more content writing trend to avoid is replacing letters with characters, for example “$ave ₵ash” or “see u l8r.” This causes predictable issues for translation and screen readers, but it also can show up incorrectly for anyone. If you have an article titled “$ave ₵ash” it will show up in the url as something like this: yoursite.com/news/ave-ash, which could lead to some confusion when sharing links. The “u” in “see u l8r” would most likely be understood by a non-visual user, but would be impossible to translate.

Writing Accessible Links

Writing good link titles is important, and once you understand how non-visual users navigate a page, it’s easier to accomplish. These links could be inline links, such as a word in a sentence, or could stand alone, such as a button. Regardless, what you want is for link titles to be able to stand on their own. This is because one navigational tool that assistive technology provides users with is a list of links that appear on the page. Imagine a list of links that says “click here,” “learn more,” and “download.” These links don’t give the user any context or information about where the links will go. Instead, create links with text that gives users an understanding of what exactly that link will be doing. No user wants to waste time clicking on a link gives them an unexpected result.

W3.org gives these as examples of successful links (URI refers to the link destination):

A link contains text that gives a description of the information at that URI

A page contains the sentence "There was much bloodshed during the Medieval period of history." Where "Medieval period of history" is a link.

A link is preceded by a text description of the information at that URI

A page contains the sentence "Learn more about the Government of Ireland's Commission on Electronic Voting at Go Vote!" where "Go Vote!" is a link.

Meaningful link text also helps users tabbing through a page from link to link. Users can more easily navigate and determine where to go next without spending more time than wanted on an intermediary page.

Learn more about link accessibility at w3.org.

Writing Good Alternative (Alt) Text

Images that you add to your page need good alt text. When using a content management system, you’ll see a field show up when you add an image, asking for alt text. Alt text allows non-visual users to get the same basic information that the image is giving to a visual user. It is what shows if an image doesn’t load, whether because of a broken image link(?) or a user’s limited internet access. It also provides information to search engines.

Writing good alt text can feel a bit tricky at first. What you want is for your alt text to communicate the content and function of the image. Think of alt text as what you would want to appear in the place of the image if you couldn’t use it. You’ll want to be succinct in describing the image, and avoid any redundancy with the text around it. Screen readers will know that it’s an image, so don’t add text like “image of…” Think about what information is and isn’t helpful, and why you’re adding an image in the first place. Is it just to take up space next to text, or is there something important being conveyed through that image? An image of students on a quad conveys information about student life at the university, whereas a cartoon image of a backpack likely doesn’t add any information.

Example of an alt text field in Drupal8.

Sometimes the alt attribute of an image should be empty. The alt attribute is the piece of HTML that is holding the alt text you enter when you first add an image. You may instead have a label below your image that is visible to all and acts as alt text. You wouldn’t want a screen reader to read out what would ultimately be the same text twice, so you’ll want an empty alt attribute on the image. The only instance where you want no alt text at all is when an image is only decorative, such as a swirling line between text sections or a generic image added only to break up the text (like the previous backpack example). Alternative text may be a required field when you add an image, in which case adding empty alt text by typing a single space in the field might work for you. If this doesn’t work, you may want to talk to a developer about making alt text optional. Consider how many content editors your site has, and if they all have accessibility training. If it is possible that a lot of images that need alt text could end up without it, it may be best to keep it required and minimize using images that don’t add meaning to a page. If the image has alt text in a caption already and you need to add something into the alt text field to be able to save it, try to add context that isn’t already clear from the caption. In most cases you will want alt text anyway, but ask yourself if the alt text you’re adding will be a help or an unnecessary hindrance to a non-visual user.

Wikipedia shows the alt text below the image and the alt attribute stays empty.

When an image is linked, and is the only thing in the link, the alt text needs to describe the function of the link. This is because the link doesn’t have any other text in it, so any clue as to where the link is going to go is taken from the alt text. In this case, you can write alt text as if you were writing link text.

For some great examples of how to write alt text, take a look at the list provided by webaim.org.

Conclusion

Once you understand how different users are experiencing your content, writing with accessibility in mind starts to get easier. It’s not always the most exciting and creative part of writing content, but it can be a rewarding experience to continually remind yourself to think about users that often can be overlooked. Putting yourself in someone else’s shoes can help build empathy and make the web, and particularly your piece of it, a more positive space for all.

Mar 26 2020
Mar 26

First, I want to thank everyone in the Drupal community for all you have done in the past to support each other and the Drupal project. I was fortunate when I started my Drupal journey back in 2011 to have been introduced to and embraced by the Drupal community right from the start. I have met so many incredible people who I now consider friends. My life wouldn’t be what it is today without so many of you. Thanks to the awesome community for that.

As one of the community-elected members of the Drupal Association Board of Directors, I am reaching out to the Drupal community for your support.

Please start by taking a few minutes to read the recent post by Dries Buytaert (founder and project lead of Drupal) and the recent post by Heather Rocker (Executive Director of the Drupal Association) regarding the uncertain times which the Drupal Association faces with DrupalCon Minneapolis due to the COVID-19 pandemic. These posts explain why it is so important for folks to step up now and help support the Drupal Association.

So how can the Drupal Community help?

What can an organization do?

What can an individual do?

What can everyone do?

  • Reach out to companies and organizations that you support that depend on Drupal and encourage them to join the Drupal Association as a Supporting Partner or to make a Donation. So many great organizations depend on Drupal for their websites and functionality, yet do not know that the Drupal Association exists or understand why supporting the DA is so important to the Drupal project.  (Template to potentially be used as a starting point for your email)
  • Reach out to those in your local Drupal communities to encourage folks to learn about how the Drupal Association supports the Drupal project and why it’s important for everyone in the Drupal Community to help the Drupal Association during these uncertain times.
  • Share this message on social media to help us reach as many folks as possible.

Thanks to all the incredible folks in the Drupal Community for your help. I look forward to seeing everyone online for now and can’t wait until we can meet in person once again. Stay safe and healthy!

Leslie Glynn
Drupal Association At-Large Board Member
Drupal.org - leslieg

Mar 18 2020
Mar 18

The Drupal 8 core Views module is a big part of why Drupal 8 websites work so well. It takes advantage of Drupal’s structure to create features from recommended content to directories and search pages. However, you can quickly run into complications when implementing a view, especially if your website is multilingual. So get ready to learn how to display multilingual Drupal 8 views of entities (such as nodes, media, and taxonomy terms) as well as entities indexed through the Drupal 8 Search API module.

Use case

A multilingual Drupal 8 website with these guidelines:

  • the default language is English
  • users can choose to view the site in French or Spanish regardless of available translations
  • if an entity does not have the requested French or Spanish translation, then display the English version

What could go wrong with multilingual Drupal 8 views? It starts with how views get data and how translations are stored in Drupal. The database contains separate rows for each translation of an entity, so when the view queries it without specifying a language, it can return duplicates of the same entity. However, if you filter by the page’s interface language, the database will only return entities translated in the page’s language. Additionally, if this is a view of indexed entities, then the language rendering options which fix the above issues are not available. Because of this discrepancy, regular entity views and indexed entity views need different solutions.

Regular entity views

If you are unfamiliar with adding a filter to a view, check out these instructions from drupal.org.

1. In the view edit page, find the FILTER CRITERIA section on the left side under the FIELDS section. Click ADD to get the FILTER CRITERIA pop-up.

2. Next, select Translation Language and click APPLY.

3. Then, in the next pop-up, select Site’s default language, and click APPLY again.

4. Back on the view edit page in the LANGUAGE section, click on the setting underneath Rendering Language. 

5. In the pop-up, change the select box to Interface text language selected for page and click APPLY.

6. Save your view!

This means that all the entities in your view will display in the requested language, but default to your default language so nothing gets left out. This filter also removes any duplicates, because the language is held constant during the query.

Keep in mind that if any entities in your view do not have a version in the default language, they will not show up, even if the page is set to the language they do have. This was not an issue for the example site as all the content started with English and was later translated, but this could create problems if your content is originating from multiple languages.

Indexed entity views

This was done using version 8.x-3.8 of the Search API Solr module. Since Search API Multilingual Solr Search was not merged into this module until 8.x-2.x, older versions of Search API Solr may not have this functionality (namely the “Language (with Fallback)” field which was added to fix this problem).

1. In the admin menu, go to Configuration > Search and metadata > Search API.

2. Edit the search index your view is pulling from and go to the Fields tab.

3. Click ADD FIELDS.

4. In this pop-up under Global fields, click ADD next to Language (with Fallback).

5. Save this configuration and re-index.

6. In your view’s filter criteria, add the Language (with Fallback) field and set it to Interface text language selected for page.

Using multiple languages complicates everything in Drupal, but the Drupal community is always developing patches, updates, and modules to make it easier. If you have a multilingual Drupal website in need of custom solutions, see our contact page to get in touch!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web