Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Jun 22 2020
Jun 22

It’s nearly a decade since the release of Drupal 7. During this time, we have seen new legislation in web accessibility, privacy (GDPR), the rise of mobile internet, and the proliferation of high-performance devices. 

The way we interact through technology has changed too. Customer expectation has risen, and interaction has become automated, facilitated by the integration of CRMs and marketing tools. 

The case for 'Versions'

These social changes are why ‘versions’ of technology are released. When the world changes in such a fundamental way, it is illogical to make a historic version continue to fit. Instead, new versions are built with the way we communicate at their source.

Drupal 7 was created in an unrecognisable world by today’s standards, and by staying on D7, you remain in that past world.

If you wish to remain secure, keep pace with innovation, consumer expectations, and meet modern digital standards, it is necessary to migrate your website to a CMS version built for the new world. 

These new requirements are why Drupal 8 and most recently Drupal 9, which I will come onto later, have been released.


What happens at Drupal 7’s End of Life?

In November 2021 Drupal 7 reaches “End of Life”. It is important to understand what this means to your organisation:

  • The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 core or contributed modules (additional components for your website), themes, or other projects.
  • Drupal 7 will no longer be supported by the community at large. The community at large will no longer create new projects, fix bugs in existing projects, write documentation, etc. around Drupal 7.
  • After November 2021, using Drupal 7 may be flagged as insecure in 3rd party scans as it no longer gets support.
  • Best practice is to not use unsupported software, it would not be advisable to continue to build new Drupal 7 sites.

It is important to appreciate that your website does not suddenly become insecure come November 2021, rest assured we present you several options, detailed below.


Drupal 8: What’s new?

Drupal 8 is a massive leap forward for the community and the organisations using it.

There are so many reasons why Drupal 8 (and 9) implementations appeal to Drupal 7 site owners. Here are a few which stand out:

  • Content authoring experience designed with marketers in mind
  • Drag and drop page builder
  • Flexible page layouts with components
  • Introduce modern headless front end
  • Mobile-first by default
  • Fast page load times, great for end-users and SEO alike
  • Media library simplifying work with video, images and documents
  • Social integration
  • Easily exchange data with CRM, marketing and back-office systems
  • WCAG 2.1 accessibility
  • Ability to introduce personalisation


How to decide your Drupal 7 strategy

Your path forward depends upon your organisation’s attitude towards the Drupal 7 site. Which category does your site fall into?

Category 1 Site Owners
  • Our website is critical to our business operation.
  • Our website needs a redesign.
  • To perform efficiently, we additional features now or in the future.
  • Our website must comply with accessibility and/or GDPR legislation.
  • Our website is in active development.

Recommendation: Drupal 8 Re-platform (Click or keep scrolling)

Category 2 Site Owners
  • We have no plans to develop further features.
  • We will retire the site in the next 12-24 months.
  • Our site content and design will remain the same for a number of years.

Recommendation: Drupal 7 Long Term Support program (Click or keep scrolling)

Category 1 Site Owners:

Drupal 8 replatform 

To help you consider what approach to take, consider which of the next set of categories your site falls into. Each results in all the benefits Drupal 8 offers, but takes a different journey to get there.

Level 1/3: Your site is great as is.

Your site functions with minimal issues. You want to spend little time planning and you're migrating for security reasons.

Level 2/3: In need of a refresh.

You need a visual refresh and to evaluate some features, but on the whole, your site operates just fine.

Level 3/3: Time for a big rethink.

Your site doesn't meet your requirements or business goals. It's time for a big rethink.

Recommendation: Lift and shift £

Maintain the same functionality and look-and-feel, but with a new Drupal 8 CMS.

Steps: A Drupal 8 migration.

Recommendation: Minor upgrade ££

A solution similar to your existing site, with a design refresh.

Steps: Short planning phase to deliver new wireframes, creative design, and a Drupal 8 migration.

Recommendation: Major upgrade £££

A solution significantly different to your existing site with a totally new design.

Steps: A discovery, definition, and full design process before the Drupal 8 migration.

Category 2 Site Owners:

Drupal 7 long term support

Staying on Drupal 7 is an option only if you subscribe to extended support, commercially available security updates are made available via a subscription model. This will be available until 2024.

Additionally, patching of Symfony and PHP will be necessary. Over time this option becomes less attractive since innovation is not here, the burden to maintain a secure site will grow.

What about Drupal 9?

Drupal 9 was released June 3rd 2020, built from the final version of Drupal 8. It can be considered a housekeeping release. The release removes features no longer necessary and any “deprecated code” to maintain compatibility with key underlying third-party systems like Symfony. These third-party systems that are also benefiting from security and performance updates. These changes are all centred around keeping pace with the modern web.

Moving to Drupal 8 means you are ready for Drupal 9. Once a majority of modules are ported to Drupal 9, many of which already are, only then should you update to 9.

If you migrate to Drupal 8, ensure your new site does not reference features deprecated in Drupal 9. If you do this, moving between Drupal 8 & 9 will efficient and return great value.

“Moving between Drupal 8 & 9 is the easiest upgrade in a decade.”

Drupal 8 migration audit

When deciding and planning for a migration, you must audit and consider the following:

  • Integrations and 3rd Party features
  • Bespoke modules and design
  • Front end styling and customer experience
  • Live data systems
  • Data housing and quality
  • Page and content structure, volume, and quality
  • Back office processes
  • Workflows and approval systems
  • Security
  • Accessibility

It would be a missed opportunity to not tell you that we offer this service as both an initial review and an extensive audit. If you require these services, please inform me of your concerns and website address on our contact page.

Building a business case for a Drupal upgrade

Once you have identified the risks of Drupal 7, you may need to convince your colleagues, superiors, and peers. We have developed business cases for Universities, the Public Sector, Membership bodies, Legal Professionals, and Not-For-Profit organisations.

The crux comes from the opportunity deficit. While the risks of security and accessibility are clear to most, the opportunity deficit is created first by your technical knowledge, and finally by your creative application. Having been in the depths of Drupal since the beginning, we know the hidden potential of Drupal, and as such, can help you identify the business-critical opportunity a migration can bring.

Useful links

University of West London D7 to D8 Migration

Drupal 7 Roadmap on Drupal.org

Founder of Drupal, Dries' Drupal 7, 8 and 9 Blog

Accelerated Drupal Migrations with CTI Digital

Feb 20 2020
Feb 20

Drupal Camp London is a 3-day celebration of the users, designers, developers and advocates of Drupal and its community! Attracting 500 people from across Europe, after Drupalcon, it’s one of the biggest events in the Drupal Calendar. As such, we're pleased to sponsor such an event for the 6th time!

Drupalcamp weekend (13th-15th March) packs in a wide range of sessions featuring seminars, Birds of a feather talks, Sprints and much more. Over the weekend there are 3 Keynotes addressing the biggest upcoming changes to the technical platform, its place in the market, and the wider Drupal community.

Check out all of the accepted sessions on the Drupal Camp London website here. Or keep reading to see our highlights…

CXO Day - Friday 13th of March

From Front Room to Front Runner: how to build an agency that thrives, not just survives - Talk from Nick Rhind

Few digital agency start-ups reach their first birthday, let alone celebrate over 16 years of success. Our CEO Nick Rhind will be sharing anecdotes and advice from 2 decades of building the right teams to help his agency group, CTI Holdings, thrive.

Catch up with Nick, or any of our team attending Drupal Camp by connecting with them on LinkedIn, or via our contact form.

Come dine with us - Agency Leaders Dinner London

Hosts Paul Johnson (CTI Digital), Piyush Poddar (Axelerant), and Michel Van Velde (One Shoe) cordially invite agency leaders to join them for a night of meaningful discussions, knowledge sharing, and of course great food, excellent wine, and the best company you could ask for. Details of the dinner can be found here.

DCL Agency Leaders Dinner 2020

Agency Leaders Dinner London

Drupal Camp Weekend

Drupal in UK Higher Education - A Panel Conversation

Paul Johnson, Drupal Director at CTI Digital, will be hosting influential bodies from the Higher Education community as they discuss the challenges facing universities in a time of light-speed innovation and changing demand from students. In addition, they will explore the role Drupal has played in their own success stories and the way open source can solve problems for other universities. Drupal camp panel details available here.

The Panellists:

Adrian Ellison, Associate Pro Vice-Chancellor & Chief Information Officer University of West London - Adrian has been involved in Registry, IT and Library Services in higher education for over 20 years. He joined UWL in 2012 from the London School of Economics, where he was Assistant Director of IT Services. Prior to that, he was IT Director at Royal Holloway, University of London, and held several roles at the University of Leeds.

Adrian is a member of the UCISA Executive Committee, representing the voice of IT in UK education. He has spoken about information technology at national and international conferences and events and co-wrote the Leadership Foundation for Higher Education’s 'Getting to Grips with Information and Communications Technology' and UCISA’s ‘Social Media Toolkit: a practical guide to achieving benefits and managing risks’.

Billy Wardrop, CMS Service Support Officer at Edinburgh University - Billy is a Senior Developer with 15+ years experience and the current technical lead for the migration to Drupal 8 at The University of Edinburgh. He has worked with many platforms but his passion lies in developing websites and web applications using open source such as Drupal, PHP, JavaScript and Python. Billy is an advocate in growing the open-source community. As part of his role in the university, he regularly mentors at events and encourages software contribution. 

Iain Harper Head Of Digital, Saïd Business School, University of Oxford - Iain started his career at leading medical insurer MPS, developing their first online presence. He then ran digital projects at a leading CSR consultancy business in the Community before joining the Civil Service. Iain worked with the Government Digital Service on Alphagov, the precursor to GOV.UK. He then joined Erskine Design, a small digital agency based in Nottingham where he supervised work with the BBC on their Global Experience Language (GEL). He now leads the digital team at Oxford University’s Saïd Business School.

Open source has won. How do we avoid dying from success? - A Panel Conversation

Drupal, founded on a philosophy of open source, has steadily grown into a global community, a feat some may label as having achieved ‘Success’. Drupal users and contributors will be discussing the sustainability of Drupal and the future of open source in an open panel session.

What are the challenges faced by different roles? How can we make the whole ecosystem fair and future proof? What does an open source business model look like? 

Join our very own Paul Johnson and Drupal panellists for this thought provoking discussion on the future of open source. More details on the session are available here.

Why should you attend Drupal Camp?

Share useful anecdotes and up-to-date knowledge 

Discover the latest in UX, design, development, business and more. There’s no limit to the types of topics that could come up...as long as they relate to Drupal that is!

Meet peers from across the industry

From C-Level and Site managers to developers and designers over 500 people attended last year. Meet the best and brightest in the industry at talks and breakouts.

Find your next project or employer

A wide variety of business and developers attend Drupal Camp, make the most of it by creating connections to further your own career or grow your agency team.

Mar 13 2019
Mar 13

Note: This post refers to Drupal 8, but is very applicable to Drupal 7 sites as well

Most Drupal developers are experienced building sitewide search with Search API and Views. But it’s easy to learn and harder to master. These are the most common mistakes I see made when doing this task:

Not reviewing Analytics

Before you start, make sure you have access to analytics if relevant. You want to get an idea of how much sitewide search is being used and what the top searches are. On many sites, sitewide search usage is extremely low and you may need to explain this statistic to stakeholders asking for any time-consuming search features (and yourself before you start going down rabbit holes of refinements).

Take a look for yourself at how the sitewide search is currently performing for the top keywords users are giving it. Do the relevant pages come up first? You’ll take this into account when configuring boosts.

Using Solr for small sites

Drupal 8 Search API comes with database search included. Search API DB has come a long way over the years and is likely to have the features you need for smaller sites. Using a Solr backend is going to add complexity that may not be worth it for the amount of value your sitewide search is giving. Remember, if you use a Solr backend you have to have Solr running on all environments used in the project and you’ll have to reindex when you sync databases.

Not configuring all environments for working Solr

Which takes us to this one. If you do use Solr (or another server-side index) you need to also make sure your team has Solr running on their local environments and has an index for the site. 

Your settings.php needs to be configured to connect to the right index on each environment. We use Probo for review sandboxes so we need to configure our Probo builds to use the right search index and to index it on build.

Missing fields in index or wrong type

Always included the ‘Rendered HTML’ field in your search index rather than trying to capture every text field on all your content types and then having to come back to add more every time you add a field. Include the title field as well, but don’t forget to use ‘Fulltext’ as its field type. Only ‘Fulltext’ text fields are searchable by word.

Not configuring boosts

In your Processor settings, use Type-specific boosting and Tag-boosting via HTML filter. Tag boosting is straightforward: boost headers. For type-specific boosting you’re not necessarily just boosting the most important content types, but also thinking about what’s in the index and what people are likely looking for. Go back to your analytics for this. 

For example, when someone searches for a person’s name, are they likely wanting the top result to be the bio and contact info, a news posting mentioning that person, or a white paper authored by the person? So, even if staff bios are not the most important content on the site, perhaps they will need to be boosted high in search, where they are very relevant.

Not ordering by relevance

Whoops. This is a very common and devastating mistake. All your boost work be damned if you forget this. The View you make for search results needs to order results by Relevance: Descending.

Using AJAX

Don’t use the setting to ‘Use AJAX’ on your search results View. Doing so would mean that search results don’t have unique URLs, which is bad for user experience and analytics. It’s all about the URLs not about the whizzbang.

Not customizing the query string

Any time you configure a View with an exposed filter, take the extra second to customize the query string it is going to use. ‘search’ is a better query string than ‘search_api_fulltext’ for the search filter. URLs are part of your user interface.

No empty text

Similarly, when you add an exposed filter to a search you should also almost always be adding empty text. “No results match your search” is usually appropriate.

Facets that don’t speak to the audience

Facets can be useful for large search indexes and certain types of sites. But too many or too complex facets just create confusion. ‘Content-type’ is a very common facet, but if you use it, make sure you only include in its options the names of content types that are likely to make sense to visitors. For example, I don’t expect my visitors to understand the technical distinction between a ‘page’ and a ‘landing page’ so I don’t include facet links for these.

A screen shot of facets in DrupalYou can exclude confusing facet options 

Making search results page a node

I tell my team to make just about every page a visitor sees a node. This simplifies things for both editors and developers. It also ensures every page is in the search index: If you make key landing pages like ‘Events Calendar’ as Views pages or as custom routes these key pages will not be found in your search results. 

One important exception is the Search Results page itself. You don’t want your search results page in the search index: this can actually make an infinite loop when you search. Let this one be a Views page, not a Views block you embed into a node.

Important page content not in the ‘content’

Speaking of blocks and nodes, the way you architect your site will determine how well your search works. If you build your pages by placing blocks via core Block Layout, these blocks are not part of the page ‘content’ that gets indexed in the ‘Rendered HTML.’ Anything you want to be searchable needs to be part of the content. 

You can embed blocks in node templates with Twig Tweak, or you can reference blocks as part of the content (I use Paragraphs and Block Field.)

Not focusing on accessibility

The most accessible way to handle facets is to use ‘List of Links’ widget. You can also add some visually hidden help text just above your facet links. A common mistake is to hide the ‘Search’ label on the form. Instead of display: none, use the ‘visually-hidden’ class.

Aug 22 2016
Aug 22

The Drupal accessibility initiative started with some advancements in Drupal 7 to ensure that Drupal core followed the World Wide Web Consortium (W3C) guidelines: WCAG 2.0 (Web Content Accessibility Guidelines) and ATAG 2.0 (Authoring Tool Accessibility Guidelines).
Many elements introduced in Drupal 7 were improved and bugs discovered through intensive testing were addressed and integrated to Drupal 8 core as well. Let’s take a tour of the accessibility in Drupal 8 !

Contrasts improved

Drupal’s accessibility maintainers improved contrasts in core themes so people that suffer from colorblindness are able to visit websites clearly. It is also good when visiting the website under bright sunlight, on mobile for instance.

A screenshot that compares Bartik headers in Drupal 7.43 and Drupal 8

Color contrasts in Bartik theme in Drupal 7.43 and Drupal 8.

See the related WCAG 2.0 section about contrasts.

Alternative texts for images

The alternative text for images is really useful for blind people who use screen readers. They can understand the meaning of an image through short descriptive phrases. This alternative text is now by default a required field in Drupal 8.

A screenshot showing that the alternative text is required when uploading an image in Drupal 8.

The alternative text for an image is required by default in Drupal 8 content edition.

See the related WCAG 2.0 section about alternative texts.

More semantics

Many accessibility improvements are hard to see as it involves semantics. Drupal 8 uses HTML5 elements in its templates which add more meaning into the code. For instance, assistive technology such as screen readers can now interpret elements like <header>, <footer> or <form>.

Moreover, WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) additional markup really improved semantics using:

  • landmarks to identify regions in a page, for instance: role="banner" ;
  • live regions to indicate that an element will be updated, for instance: aria-live="polite";
  • roles to describe the type of widgets presented, for instance: role="alert";
  • properties: attributes that represent a data value associated with the element.

See the related WCAG 2.0 sections about semantics.

Tabbing order

Drupal 8 introduces the TabbingManager javascript feature. It enables to constrain tabbing order on the page and facilitates navigation with keyboards. It is really helpful to guide a non-visual user to the most important elements on the page and minimize confusion with screen readers.

See the related WCAG 2.0 section about keyboard operations.


Drupal 8 accessibility involves many improvements regarding forms in Drupal 8.

In Drupal 7, all errors were displayed by default on top of the form and fields were highlighted in red. It was not right for colorblind people to understand where the errors were.
In Drupal 8, there is an experimental option to enable form inline errors and an error icon is displayed next to the field. Nevertheless, note that this feature is not enabled by default as there are still some pending issues.

Screenshot of a password field highlighted in red with an error message below "The specified passwords do not match"

The error message is displayed below the field when the Form Inline Error module is enabled.

See the related WCAG 2.0 sections about error identification.

Regarding the form API, radios and checkboxes are now embedded in fieldsets to meet WCAG compliance. Indeed, grouping related elements will help screen readers to navigate in complex forms. Plus, all fields have a label associated with the right element using the “for” attribute.

Here is an example of HTML code for radio buttons:

Poll status

See the related WCAG technical section about fieldsets

Tables and views

As Views UI module is in core now, it became accessible.
The views tables markup is more semantic. Data cells are associated with header cells through “id” and “headers” attributes. It is also possible to add a <caption> element to explain the purpose of the table and a <summary> element to give an overview on how the data is organized and how to navigate the table.
Plus, the “scope” attribute enables to explicitly mark row and column headings.

Here is an example of a table HTML code generated by a view:

Content type <a href="https://blog.liip.ch/admin/structure/types/manage/article">Article</a> <a href="https://blog.liip.ch/admin/structure/types/manage/article">Article</a>

Content type

<a href="/admin/structure/types/manage/article">Article</a>

<a href="/admin/structure/types/manage/article">Article</a>

Details for the table

Description for details

See the related WCAG section about tabular information.

Hidden elements

Using "display:none;" CSS styling can be problematic as it will hide elements for both visual and non-visual users and consequently, screen readers will not be able to read them.
Drupal 8 accessibility maintainers decided to standardize in the naming convention of HTML5 Boilerplate using different classes to hide elements:

  • hidden“: hide an element visually and from screen readers;
  • visually-hidden“: hide an element only visually but available for screen readers;
  • invisible“: hide an element visually and from screen readers without affecting the layout.

Aural alerts

Users with visual impairment will not be able to see all visual updates of the page such as color changes, animations or texts appended to the content. In order to make these changes apparent in a non-visual way, Drupal provides the Drupal.announce() JavaScript method which creates an “aria-live” element on the page. This way, text appended to the node can then be read by a screen reading user agent.

Here is an example of a code using the aural alert:

Drupal.announce('Please fill in your user name', 'assertive');


Drupal.announce('Please fill in your user name', 'assertive');

The first parameter is a string for the statement, the second is the priority:

  • polite“: this is the default, polite statements will not interrupt the user agent;
  • assertive“: assertive statements will interrupt any current speech.

See the related WCAG technical section about how to use live regions to identify errors.

CKEditor WYSIWYG accessibility

Drupal community helped improving CKEditor accessibility.
First of all, the WYSIWYG editor now comes with keyboard shortcuts which are beneficial for both power users and keyboard-only users.
Drupal 8 implements more semantic elements. For instance, the user can create HTML tables with headers, caption and summary elements. <figure> and <figcaption> HTML5 tags are also available to add captions to images.
Moreover, every image added through CKEditor are required by default, as it is on image fields.

CKEditor module also introduces a language toolbar button so that users can select a part of text and specify the language used. Screen readers will be able then to choose the appropriate language for each content.

See the related WCAG technical section about language attributes.

Finally, there is an accessibility checker plugin for CKEditor. It is not in core yet as a CKEditor issue blocks its integration, you can find more information on the related Drupal issue queue. However, you will find a module that implements it currently: ckeditor_a11checker.

All these options will definitely help users to generate accessible contents.


Drupal core maintainers accomplished great enhancements regarding accessibility in Drupal 8. These accessibility features will definitively be beneficial to keyboard-only users, low-vision users and colorblind people but will also be good for the usability and the SEO of your website.
Nevertheless, there is still work to be done to make Drupal 8 core fully accessible and Drupal needs contributors to tackle the remaining issues.

If you want to learn more about Drupal 8 accessibility, you can watch the presentation about “How Drupal 8 makes your website more easily accessible” given by Mike Gifford, one of the main accessibility core maintainer for Drupal.

Jan 28 2016
Jan 28

Generally speaking hiding content goes alongside a bit of javascript that unhides the content under certain circumstances (think hamburger menu).

Sometimes the content improves accessibility but is considered visual noise (says the designer).

So as the developer you have a lot of ways to... pat the cat(?) But not all cats react the same to being patted :D

Hiding with Javascript

jQuery gives us .hide(), .fadeOut() and .slideUp() to use, which all use the CSS rule display:none.

Now display:none is a very effective way of hiding things but it has some caveats;

Screen readers cannot see it or any of it's children.

Any focusable children (like fields or links) are no longer focusable.

When used inline, as these jQuery functions do, it can only be undone by disabling Javascript or using .show(), .fadeIn() or .slideDown(). **plus inline CSS = yuck!**

Hiding with Classes


Drupal 7 provides the .element-hidden class which also uses display:none but having it on a class means we have more control.

Disabling Stylesheets will show what was hidden, though disabling Javascript will only show the hidden element if the .element-hidden class was added by Javascript in the first place.

Using classes in jQuery is super easy, instead of .show() and.hide() you can do it all in one line with .toggleClass()

.element-hidden {


The Zen themes starterkit gives us the .hidden class which is EXACTLY the same as .element-hidden but shorter and easier to remember. The simplified class name also reflects a change in Drupal 8 core.

.hidden {


Zen also adds the .js-hidden class which is also the same as .element-hidden but uses the .js class that Drupal adds to the HTML element to check that Javascript is enabled in the browser.

So .js-hidden will ONLY hide something if Javascript is enabled, which solves caveat 3!

html.js .js-hidden {

But what about screen readers and focus?

Hiding without hiding


So Drupal 7 also provides the .element-invisible class which DOES NOT use display:none but instead hides the element with CSS by more or less making it really really small so you just can't see it.

But screen readers completely ignore this CSS and can read the content normally. This is great for hidden text content like in inactive Tabs, and even better for those social media icons which really should have some "Follow me I'm amazing" content.

Anything focusable inside it is also still focusable! Also great for those links in your hamburger menu. Though extra care does need to be taken here...

Focusing on something that is visually hidden creates a "keyboard trap" for any sighted keyboard navigators, because they cannot see where the focus has gone.

They have to continue tabbing past the hidden element to get it back. One workaround is to use Javascript to remove the .element-invisible class if it or any of it's children have focus.

It's also worth noting that unless the class was added by Javascript, disabling Javascript will have no affect on the hidden element.

.element-invisible {
 position: absolute !important;
 clip: rect(1px, 1px, 1px, 1px);
 overflow: hidden;
 height: 1px;


This one, like .hidden is provided by Zen and is basically the same as .element-invisible but again, easier to remember and matches Drupal 8.

It also describes the behavior a bit better, in that is really is only visually hidden, and not hidden in any other way.

.visually-hidden {
 position: absolute !important;
 clip: rect(1px, 1px, 1px, 1px);
 overflow: hidden;
 height: 1px;
 width: 1px;


Another Drupal 7 class, this one requires the .element-invisible class to also be on the same element, and uses CSS to make is visible again but only on focus.

Perfect for "Skip links" and the like. Though a child element that is focusable (like a hidden forms fields) is still hidden, we still need Javascript to fix that.

.element-invisible.element-focusable:focus {
  position: static !important;
  clip: auto;
  overflow: visible;
  height: auto;


A simplification of .element-focusable, provided by Zen, that moves everything to one class. This one differs from the changes in Drupal 8 slightly by combining the classes but follows the BEM Modifier naming pattern.

.visually-hidden--focusable {
 @extend .visually-hidden;
 &:focus {
   position: static !important;
   clip: auto;
   height: auto;
   width: auto;
   overflow: auto;


Avoid using the jQuery functions entirely. If fading or sliding animations are needed your friendly front-end team can do them in CSS.

Overall the ones in Zen should be used over the ones provided by Drupal for consistency sake, and that they can be configured.

  • If you are toggling visibility in Javascript and you know it shouldn't be focusable use .js-hidden
  • If you are toggling visibility in Javascript and it's content DOES need to be focusable make sure you remove the class from the parent on focus.
  • If you are hiding text content but want unsighted people to access it use .visually-hidden
  • If you are hiding a focusable element itself, and want sighted keyboard users to interact with it use .visually-hidden--focusable
accessibility Drupal 8
Jan 05 2016
Jan 05

We’ve been thinking about code reviews lately here at Advomatic.  Fellow Advo-teammate Oliver’s previous post covered the whys of our code review process, and Sarah covered the hows when she did a overview of some tools we use regularly.  This post focuses on the front-end side, and deals more with the whats of front-end code review… as in:

  • what are our main overall goals of the code we write?
  • what are the common standards we follow?
  • and what quick-and-easy changes can we make to improve our front-end code?

Guiding Front-end Coding Principles

In the world of front-end development, it seems like there is an intimidating, constantly expanding/changing set of tools and techniques to consider.  The good news is that there is a pretty dependable set of widely accepted working guidelines that aren’t tool-specific.  We really try to consider those guidelines first when we are reviewing a peer’s code (and the technical approach they have taken):

  • Write valid, semantic HTML5 markup – and as little markup as needed
  • Enforce separation of content, functionality/behavior, and presentation
  • The site should function without the use of JavaScript, which when added, is only used to progressively enhance the site. Visitors without JavaScript should not be crippled from using the site.

Best Practices

Sometimes there are a million ways to solve a single problem, but I think we do a good job of not pushing a particular tool or way of dealing any of those problems.  Instead, we’ll see if the code is efficient and if it can stand up to questions about its implementation, as far as best practices go.  For example:

  • Is there logic-related PHP in templates that should be moved to template.php?
  • Can JS be loaded conditionally from a custom module or the theme’s template.php via

    so it doesn’t load on pages that don’t need it?

  • Is the project already using a DRY CSS methodology elsewhere?  BEM or SMACSS maybe?  Should it be used here?
  • Are we generally following coding standards?
  • Are we coding with web accessibility guidelines in mind?

Minimal Effort Refactoring or “Grabbing the Low Hanging Fruit”

Refactoring code as an afterthought (or as a reaction to some problem down the road), is never fun – it pays to be proactive.  Ideally, we should always be retooling and improving our code as we go along as we get more information about the scope of a project and if the project budget and/or timeline allows for it.  When we look at a peer’s code changes, what kinds of things can we suggest as a quick and easy “upgrade” to their code?

  • Markup:
    • Instead of that ugly Drupal-default markup we’re working with, can it be swapped out with an appropriate HTML5 replacement element?
    • Is that inline JS or CSS I see in the markup?  Crikey, what’s that doing here?!?
    • Do we really need all these wrapper divs?
    • Is this the bare minimum markup we need?
  • CSS/Sass:
    • Can we use an already-established Sass mixin or extend instead of duplicating styles?
    • Is this element styling worthy of a new mixin or extend that can be reused on other elements, either now or in the future?
    • Should this mixin actually be an extend (or vice versa)?
    • If the code is deeply nested, can we utilize our CSS methodology to make the selector shorter, more general, or more concise?
    • Is this selector too unique and specific?  Can it be generalized?
  • JS:
    • Does this work without JS?
    • Is there a chance this could adversely affect something unrelated?
    • Does it need to be more specific, or be within a Drupal behavior?
    • In Drupal behaviors, do selected portions of the DOM use the “context” variable when they should? For example:
      $('#menu', context)
    • Is jQuery Once being used to make sure that code is only run once?
    • Should this code only run when we are within a certain viewport size range (a breakpoint)?
    • Does it need to be killed/destroyed when the breakpoint changes?
    • Would this functionality benefit from being fired via feature detection, especially if our target browsers are old-ish?

Quick Browser QA

I know, I know.  Browser QA is not really “code review”.  However, it does go hand in hand, and makes sense to deal with when you’re reviewing someone’s code.  It is at that point that you, the code reviewer, are most familiar with your peer’s work and specific goals.

While we do a more thorough and complete test and review of work in target browsers and devices at the end of an iteration (generally every two weeks), we also do a shorter burst of quick QA during an individual ticket’s code review.  We’ll quickly check it in the latest version of major target browsers/devices – this helps us find bugs and issues that are big, visible and easy to fix.  It also ensures that they don’t pile up on us to deal with during our final iteration… which can be really demoralizing.

Back to Basics

Code reviews are great for brushing up on the basics when other parts of your work can seem very complicated.  None of this is particularly revolutionary – it helps to revisit the basics of why you do what you do from time to time. Aside from reviewing the technical aspect of the work, you can act as an outsider that can see the big picture of how this work affects the user experience… easier than someone in the trenches.  This is an important and valuable role to play as things come together on the front-end of your project.

May 16 2013
May 16

I’m a millennial, but even I remember the experience of calling the telephone operator and getting a live human to look up the number of a business or place a collect call. We have the digital means to complete lots of tasks like that today, but that doesn’t mean all of our methods are equally effective for everyone.

Drupal's new mobile-friendly toolbar“Drupal 8 will be the most accessible version of Drupal yet,” declare J. Renée Beach and Wim Leers in their Drupalcon Portland session description.

They’re both part of the Spark team, an initiative to improve the authoring experience in Drupal for everyone.

Spark is more well known for things like in-place editing and a mobile friendly toolbar, which you can see at right. But from the beginning, improving the experience for everyone has been a big priority, and one of the most exciting developments is a new aural interface.

That’s right, Drupal is getting a switchboard operator:

Drupal announce log showing three 'polite Drupal announcements'

OK, so that doesn’t look terribly exciting all on its own. But trust me, when you watch the videos of people interacting with Drupal 8 and having menus and selections read as they go, it’s pretty cool.

When I spoke with J. Renée about Drupal 8 and the nature of working on accessibility, the passion for this work really shown through. I’m really looking forward to their session with Wim, “Drupal Speaks: Aural user interfaces, new Drupal 8 accessibility features,” on Wednesday at 10:45 AM. Hope to see you there!

IB: What are we missing when we talk about accessibility right now?

JRB: I want developers to understand that accessibility is fundamental to user interface development. We tend to talk about accessibility like we talk about gender. Both have coded values. When we speak of being gendered, we are often talking about being non-male. Male is a kind of genderless base state. So is it with accessibility. When we speak of making something accessible, we tend to refer to making an interface for blind users or for users with physical capabilities that make keyboard and mouse use difficult, as examples. Visual is a kind of accessible base state.

We risk “othering” folks for whom accessibility is an issue because as developers, in general, non-visual accessibility has not been a primary concern. I know what is is like to be othered. In some ways, highlighting otherness can be an effective way to bring focus to a problem. Eventually though, we need to resolve those issues and close the loop on the otherness. We can be other and also be equal. Now is the time for front end developers to start thinking about accessibility as a multi-modal effort. We no longer have the excuse that the tools and technologies available to us do not support efficient workflows for non-visual UI development.

IB: Where is Drupal 8 going to do better?

JRB: Most importantly, we have more individual core contributors this cycle who truly believe in addressing accessibility issues. And they are all smart, wonderful people which makes working with them a pleasure!

For example, take this issue about requirement warnings during installation. For a sighted user, a warning during installation is immediately apparent. The missing requirement is made distinct with color contrast. For a blind user, they must traverse every cell in the table to discover a missing requirement. Would we ever impose such a burden on a sight user through the UI? No, not without grumbles in the issue queues at least. With more contributors invested in improving these types of non-visual details, we are polishing all the rough edges — the ones we see and the ones we don’t.

IB: How important is context in aural interfaces?

JRB: Context is important to all interfaces. As front end developers we build templates that expose context in a predictable, consumable way. As a practice we have established and then refined patterns of visual expression over the past 30-plus years.

Metaphors grounded visual pointer displays on a virtual desktop. We talk of visual affordances in rounded, gradient-embellished, reflective buttons. Skeumorphic designs bring our understanding of the physical world to bear on pixels and bits.

Where are the metaphors in aural interface design? I know of none. To me, these interfaces are flat. The metal is bare underneath them.

Perhaps non-visual interfaces have one less level of abstraction to traverse. Maybe there’s no need to translate language into symbol and then back into language. But that little bit of designer in me, that memory of a linguist I almost was, remembers being thunderstruck with insight reading Jackendoff’s unfurling of metaphor after I had just so recently fallen smitten with the strict generative grammar of early Chomsky. Jackendoff gives us a way of understanding language that starts at basic physical dichotomies — up/down and near/far — and from there offers us a model of communication. He gives us pattern. (Early) Chomsky gave us metal. So much that we humans do starts with structure that softens with time to fit our curvy, winding nature.

I want to believe that the aural interfaces we have today still just the awkward first attempts to build an abstract audio interface pattern language. That non-visual interface design is still working through its structuralist phase. We are still learning how to pack context into denser forms through non-visual expressions.

IB: Will the Drupal 8 improvements have things to offer module developers?

JRB: In Drupal 8, we are building tools that manage a couple of the trickier components of accessibility in a browser. These are:

1. Outputting audio updates

2. Managing tabbing in constrained workflows

Module developers will be able to pass a string to a method called “announce” on the Drupal object and have that string read by a screen reader.

Another method on the Drupal object called “tabbingManager” will constrain tabbable elements on the page. A developer will select those elements, either through JavaScript methods or jQuery, and pass them to the tabbingManager. Tabbing is then constrained to those elements until the constraint is superseded or released. I know that must not be completely clear, but that’s why we’re presenting a session about aural user interfaces and how we can use these new tools to build them!

Top image: Public domain. Drupal images from the drupal.org issue queue and the session slides.

May 01 2012
May 01

Posted May 1, 2012 // 0 comments

 Last summer, while sitting in the East Room of the White House, I discovered that Twitter can help me hear. This experience shed light on the parallels to the principles of Open Source technology: You never know how someone may find an innovative use for existing solutions for social, human, and/or environmental good.

When technologists like Jack Dorsey were first developing Twitter, I don’t think he stood up in front of venture capitalists and said, “This thing! It’s going to help a deaf girl in Washington, D.C., one day hear the President of the United States!”

As some background—I’m deaf and hear with a cochlear implant. It’s an awesome piece of technology that helps me hear and communicate with everyone. Because of this, technology has become a huge part of who I am. I’m constantly finding new and improved uses for technology around us to bridge the accessibility gap.

First-Ever Twitter Town Hall

Last summer, I was invited to the first-ever White House Twitter Town Hall event with President Obama and Jack Dorsey. I only had 48-hours notice, not enough time to request and find an interpreter to ensure that I’m getting access to the dialogue between President Obama and @Jack.

This Town Hall event was a really cool concept, in a little “d” democracy kind of way—anyone canObama talking to Jack Dorsey Tweet a question to President Obama with the #askobama hashtag (basically “keywords” surrounding an event) and he just may answer it. No one in the audience could. Cool, right?

Back to the story. Once Obama and @Jack started talking, they were telling jokes, laughing, the audience was laughing along, except me. Then Obama started talking about the economy and jobs, you know, the usual. Except, I wasn’t understanding anything.

I felt left out.

Pretty soon after the jokes ended and dialogue started, the LCD screens just next to President Obama projected the “tweeted” questions for Obama to answer. There. I could at least have some context to what he’s talking about – whether it’s jobs, the economy, or healthcare. I still wasn’t understanding what he was saying. I wanted to be able to tweet what he was saying to my network – I wanted to be a reporter since I was there.

And that’s when I had my “ah-ha” moment:

Audience Members as Twitter Reporters

You see, I realized that I’m not the only “reporter” in the room—not in a room full of DC’s notable technology leaders and politicians. A lot of mobile phones were out, people’s heads down staring at the screens – I immediately realized, they were live-tweeting what Obama and @Jack were saying. I quickly took an inventory of all the hashtags surrounding this event and ran a search on my iPhone twitter app, and Bingo! There were tweets that were live-tweets as quotes from President Obama as he answered the questions that were projected on the LCD screens.


 Cut through the Noise

This was a great discovery, however, there were thousands of tweets saying essentially the same thing. I wasn’t about to spend the next hour staring at my phone, filtering through all the tweets, when the President of the United States and the Founder of Twitter were sitting twenty feet in front of me. I noticed that a few Twitter accounts had good, live-quotes – not commentary and reactions – that’s what I needed; I needed someone to give me the information in an unbiased manner so that I could form my own opinions. So I figured that the “White House” and “Twitter TownHall” Twitter accounts would be good ones to follow for the event, as opposed to the thousands of tweeters.

Follow Key Accounts

I created a feed of select Twitter accounts that I felt were providing a good report of the dialogue. This became a “smart captioning” tool of sorts. I rely on closed captions on my TV to understand what the speakers are saying, so this Twitter feed became a “live, smart closed captioning” tool of sorts on my iPhone in nearly real-time. It was a lot better than the alternative: not understanding what’s going on at all.

The best part is, through this experience, the organized live-tweets enabled me to become a participant. It was a great feeling to get in the East Room of the White House.

I told a lot of my deaf friends about that experience, and although most were initially Twitter naysayers, they joined because they, too, wanted to be able to follow along with live dialogue in conference and event settings. Twitter as a “smart closed-captioning” tool was better than nothing at all.

So, viral tools like Twitter are very much like those that are Open Source. You never know how someone will use the technology, especially when it comes to improving products and services. As someone focused on accessibility in open source software for Phase2, I am excited to see how people will leverage the tools they’re building in Drupal for social, environmental, and human good.

In a lot of ways, open source software like the Drupal platform that we build here at Phase2, has the same kind of “disrupt and improve” ethos, and it’s why it’s so exciting to be working with it.

If a feature of a website separates audiences, particularly those with disabilities, Catharine McNally views it with a critical eye to find better solutions. While communicating this to web developers, she works collaboratively towards ...

Aug 02 2011
Aug 02

This is a quick walk through of how to install the Accessible Content Module for Drupal.  Accessible content uses a project called QUIAL to audit pages in your Drupal site and tell you what needs to be done in order to make them compliant.  It lets you set various levels of Accessibility standards including Section 508, WCAG 1.0 and WCAG 2.0.

We are currently investigating the validity of these tests but they appear to be at least a good starting point for identifying and correcting accessibility issues in Drupal.

Aug 10 2008
Aug 10
Illustration of interchangeable presentation Interchangeable presentation

You know the drill

If you didn't ignore the web for the past few years, you've probably heard it a million times by now: separate your content and presentation, use CSS for presentation, and say yes to semantic markup. There is no doubt that it's the right thing to do, given the sheer amount of benefits.

In a nutshell: it makes your life easier by lumping those pieces together which belong next to each other. It's somewhat akin to the proximity usability rule. It also keeps the noise down; if you want to change parts of the presentation there are no content bits in the way and vice versa. There is also a lot less overhead since those style sheets can be cached on the client side. In extreme cases it can save as much as 200kb of utterly pointless bloat. Additionally, proper CSS usage also paves the way for the ultimate killer feature: interchangeable presentation.

Reality check

In theory you can rebrand or even redesign a whole website just by replacing the style sheets. Unfortunately it's not always that easy in practice. With static sites you usually have to hack'n'slay through the markup with regex search & replace until you get usable markup. If you ever go down that route use Tidy first.

If a CMS was used things will usually look a lot better. The outer theme markup (rough layout, navigation, etc.) is externalized and can be easily replaced. And the inner article markup (i.e. the actual content) resides elsewhere. So, if the new layout requires some (outer) markup changes this won't be much of an issue. You write a new theme and that's it.

With overly verbose markup as seen on CSS Zen Garden you can also get a high degree of flexibility. Having lots of unused ids and classes in your markup isn't really feasible though. I don't know of any real website which went down that route. Zen Garden is just a content free demonstration page after all.

Legacy by default

With a CMS everything should be fine, shouldn't it? Well, almost. Typically individual articles or blog posts will be HTML or XHTML fragments. And that's already the first big issue: the content is hard coded to fit a specific digital distribution flavor from the very beginning.

For example if the site started with HTML 4.01, switching to XHTML 1.1 won't be easy. Of course you might be inclined to ask for a reason for doing so. However, the more important question is why you can't.

State-of-the-art markup is always a moving target. HTML 5 is just around the corner and so is the next incarnation of XHTML. Things will look different in 5 years. Even more so in 10 or even 20 years. The internet isn't a gimmicky piece of tech anymore. It's fairly save to say that the internet will virtually stay forever. The human span of life isn't all that long after all.

Disposable by default

Of course there is lots of disposable content. This blog isn't an exception with its technical focus. As long as none of the programming languages I talk about is the next COBOL, the article won't be of any interest for anyone a couple of years down the road.

But there is also truly timeless content. And sometimes it might be desirable to distribute it in completely different flavors. For example a "book" created with Drupal (it's a core module, which allows you to create a structured set of pages) might be also distributed as PDF, as DocBook, or even as a real physical book. As you can imagine (X)HTML fragments aren't really suited for that task.

Somewhat semantic (X)HTML

Pure semantics would address all those issues. But even semantic (X)HTML is a tad less semantic than it should be. That shouldn't be much of a surprise though. It's meant to be used to represent the structure of a typical web document in a generalized fashion and - to be fair - it does this job pretty well. But it can't be used to create the most accurate structure for any kind of document as illustrated by the following diagram:

intersection diagram Figure 1: Depressing intersection diagram

To illustrate this aspect a bit more take a look at the required markup for the eye-catcher in the upper right:

<dl style="float:right">
    <a href="http://kaioa.com/b/0808/content_presentation.svgz">
      <img src="http://kaioa.com/b/0808/content_presentation.png" width="192" height="192" alt="Illustration of interchangeable presentation" title="click for SVG"/>
  <dd>Interchangeable presentation</dd>

The inline style attribute at the very beginning isn't great, but it should always float to the right, because floating to the left would look really ugly. Why would I want to do that? I saw no benefit in creating some class just for that. Well, lets ignore that for now. The point is that we have some definition list there, which contains one term (which contains an anchor element, which contains an image) and one definition.

Basically I just used some random elements which happen to provide the required structure. It isn't a definition or a list. It's some image with some tag line.

There is even more nonsense. Why are the paths absolute? Well, to work around some issues of some aggregators. You also have to use absolute paths if you use anchor links. The width and height attributes are also pointless. They don't belong to the content. They are merely there to aid the rendering of browsers. It's a lot more pleasant to the eyes if no reflowing happens and it's also a tad quicker to render (since there is no need to recalculate the layout once the image headers are loaded).

While that stuff is somewhat mandatory it isn't related to the content itself. It shouldn't be part of handwritten markup. Even more so if it can be generated automatically.

Even headings are a pain

Even something as simple as headings are somewhat tiresome with (X)HTML. Ideally they should start with H1 and go all the way down to H6 if necessary. Steps shouldn't be omitted and there should be only one H1 heading (one root - everything else is silly). What could go possibly wrong there?

With a CMS you're only writing an (X)HTML fragment and the first headline is from a separate title field. If you look at that page this generated title will be either a first level heading or a second level heading. And over at those overview pages, which only display excerpts it's usually a second level heading, but it might be even a third level heading if those articles are grouped by author for example.

The XHTML 2.0 working draft addresses this issue with the introduction of H elements whose semantic weight is proportional to the section nesting level. The following example was directly taken from the working draft:

<h>This is a top level heading</h>
    <h>This is a second-level heading</h>
    <h>This is another second-level heading</h>
    <h>This is another second-level heading</h>
        <h>This is a third-level heading</h>

It would be great if that issue would be solved now, but you can't actually use XHTML 2.0 yet.

General (X)HTML markup issues

If a rich text editor is used you may end up with some extraneous markup. If you're unlucky it might be even invalid. Needless to say that humans also do mistakes. And validators sometimes let really horrible mistakes with devastating consequences slip through.

As you can imagine this will lead to massive problems as soon as you try to transform it into a different format. Even if only 1% of the pages require manual interaction, it will make you cry if there are thousands. With that point of view in mind you can probably understand why I'm a big fan of absolute strictness. In a perfect world all browsers would only display an error message if the markup or styling is invalid.

XSLT and alternative markup languages to the rescue

By using a different markup language than your current publishing target markup language you can avoid overly rigid coupling. It also ensures that your content will always be in a transformable state. If the need arises you can output any kind of new markup. E.g. you will be able to switch to HTML6.2 or XHTML3.2 in 2020 without having to touch the markup of any of your 5000 articles.

Just imagine the uproar. Not even 24 hours after IE12 became self-aware and deleted all copies of itself your retro geek page will be the first bigger website to make the switch to the very latest standards (which were already supported by all other browsers). That would be so cool.

All joking (and wishful thinking) aside, there are a lot of markup languages to choose from. The most popular ones are probably Markdown, Textile, Texy (I refuse to put the exclamation point there), and Wikitext. However, those options might be a tad too limited for your taste or they simply may not meet your requirements.

On the XML side there is an infinite amount of options since you can create your own schema there. You can use as many elements and attributes as you need. And if you ever need some new kind of structure you can just create it. You can also use standardized schemata such as DocBook.

In most content management systems the XSL transformation and XML validation introduces an additional step in the pre-templating phase. In Drupal this can be done during the filtering step. Unsurprisingly the XML Content module does just that. If server-sided caching is enabled this additional transformation step will be virtually free. With that extra step in place the pipeline looks like this:

XSLT diagram Figure 2: XSLT can transform any kind of XML into any other kind of XML

With my own schema in place and some automation the markup for the eye-catcher (compare with the markup above) could look like this:

<eyecatcher src="http://kaioa.com/node/84/content_presentation.svgz" alt="Illustration of interchangeable presentation" desc="Interchangeable presentation"/>

The generated markup, however, could look the same. But it could also look completely different if it's desired. Since the original graphic is an SVG, a clickable thumbnail can be created in any size. Right now I use a width of 180 pixels and a maximum height of 180 pixels and the drop shadows ramp these values up to 192 pixels.

Apparently it would be really handy if the rendering, additional effects, and post processing were fully automated. This would allow me for example to change the dimensions later on or to use different effects (e.g. a magnifying glass icon overlay). It would also allow me to get rid of that bitmap altogether as soon as it isn't required anymore.

Closing words

In retrospect it's somewhat funny that it took me that long to realize that virtually everyone (me included) creates non-portable content and that it's actually rather easy to circumvent this issue. A few years ago when I first read about XSLT in the context of web applications I didn't see the point. One could just use XTHML all the way, right?

Well, now I can see that the path from the most accurate representation to some representation (e.g. XHTML 1.1) is a one way route. It won't be possible to utilize more meaningful structures once they are introduced if you were restricted to a specific set (which didn't cover your requirements completely) at the point of creation.

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