Unimity Solutions Drupal Blog: Identification of an Open Source Video Annotations Tool for NVLI

Planet Drupal - Wed, 2016/08/24 - 2:00pm

As mentioned in our earlier blog on Video Annotations: A powerful and innovative tool for education, the most intriguing feature of the pilot version of NVLI is Video Annotation. UniMity Solutions assisted in building Annotation feature for Audio and Video assets. This involved identifying and integrating an open plugin that supported video and audio annotations and a generic annotation store module that was plugin agnostic.

Categories:

Drupal Bits at Web-Dev: Import nodes as as part of deployment using Hook Update Deploy Tools

Planet Drupal - Wed, 2016/08/24 - 5:52am

With the 7.x-1.18 release of Hook Update Deploy Tools for Drupal 7 it is now possible to export a node on a development sandbox, commit the export file to the repository, then import it using either a hook_update_N() or using drush site-deploy-import node

Pros:

  • No need to re-create a node on prod after a client approves it.
  • Early content that keeps getting wiped out by database snapshots (think style guides) can get re-created instantly with a single drush command.
  • Content imported into an existing node shows up as a revision.
  • Atomated deployment is testable and repeatable on all dev environments.
  • No uuid required.
Workflow Example:

You have a styleguide you created on your sandbox and want to deploy it to the production site.

  1.  Create the node on your sandbox (node id = 1234).
  2. Export the node to an export file.
    drush site-deploy-export 1234
  3. The command created an export file named  for the alias of the node being exported
    ex: site-deploy/node_source/helpzZzstyle-guide.txt  ('zZz' represents '/')
  4. Create a hook_update_N() to import the file on deployment
     

    <?php
    /**
     * Import a the style guide
     */
    function site_deploy_update_7129() {
      $nodes = array('help/style-guide');
      $message = HookUpdateDeployTools\Nodes::import($nodes);
      return $message;
    }
    ?>
  5. Commit the file and update hook to your repo.
  6. Push the code, run 'drush updb'
drush updb -y
Site_deploy  7129  Import a the style guide

Site_deploy: Updated: node/1234: help/style-guide - successful.
Summary: Imported Nodes 1/1.  Completed the following:
   [help/style-guide] => Updated: node/1234
  
Performed update: site_deploy_update_7129

or the import can be performed by

drush site-deploy-import  help/style-guide
Categories:

Drupal @ Penn State: Drupal 8 Theme Generation and Development Intro Using the Drupal Console

Planet Drupal - Wed, 2016/08/24 - 1:56am

Here is a screen cast of how to get started with Drupal 8 theme development.

In the video I cover:

  • using the drupal console to generate a theme from a base theme
  • creating a libraries yml file
  • adding global css to your theme
  • Using Kint with the devel module
  • debugging twig
  • adding your own twig file to your theme
Categories:

Drupal @ Penn State: Lower the Drupal 8 development barrier to entry by using the Drupal Console to generate boiler plate code.

Planet Drupal - Wed, 2016/08/24 - 1:56am

I admit that I haven't really looked at Drupal 8 too much yet. There is a variety of reasons why I haven't and I surely don't want this to turn into a forum listing the pros and cons of D8. We can leave that for another post. 

Categories:

Drupal @ Penn State: The Care and Feeding of Your Website

Planet Drupal - Wed, 2016/08/24 - 1:56am

A question on the PSU DUG Slack channel got me thinking. How is it that websites are still being constructed at Penn State without any thought being put in as to how its is going to be maintained? Or by whom?  

To be clear, I am not talking about content creation or maintenance, but maintaining the code/server/DB/etc. that supports or runs the site? Or to develop new features and functionality, going beyond just updating code or applying security patches. Of course, this is not restricted to Drupal development - there are many other examples.

Categories:

PreviousNext: Introducing Drush CMI tools

Planet Drupal - Wed, 2016/08/24 - 1:46am

Now we've got the experience of a number of production D8 sites under our belt we took the time to consolidate our CMI workflow into some useful drush commands.

And naturally we've open sourced them.

Read on to find out more about our drush CMI tools.

Categories:

GVSO Blog: [GSoC 2016: Social API] Week 13: Thanks GSoC!

Planet Drupal - Wed, 2016/08/24 - 12:07am
[GSoC 2016: Social API] Week 13: Thanks GSoC! Submitted by gvso on Tue, 08/23/2016 - 18:07

Students' final evaluations is over, and only mentors' evaluations is left. During these months, I have been working on projects to harmonize social networking functionality in Drupal and documenting them. Notwithstanding, the Social API project started as an idea for a framework in fact, the main components provide extensible functionality. Therefore, I documented the process of creating new implementers.

Tags Drupal Drupal Planet GSoC 2016
Categories:

Roy Scholten: UX meeting recap

Planet Drupal - Tue, 2016/08/23 - 11:58pm

Two meetings every week since end of march this year. Safe to say we’ve found a consistent rhythm.

And it’s working. It’s become a useful way to check in on current priorities, review patches while screensharing (visuals, transitions, flows!), decide on next steps and generally discuss hard problems without having to type so much.

The agenda for today was
  1. Roadmap – The core roadmap was updated to current state of things. Use this page to get a bird’s eye view on where Drupal core is moving towards.
  2. Ideation process – The first part of going from idea to plan got positive feedback and helpful questions and suggestions. Maybe a few words from actual maintainers and then we can make it so.
  3. Status page – We have a beautiful new design that now needs review and more code to create a complete patch. If you know your core markup and CSS, go have a look!
  4. Block place design update – An issue that iterates the design of an initial commit. We quickly discussed what the feedback should be and I added a comment to that effect right then and there. It’s an example of managing scope, pushing to focus on the actual fix first, and defer new, potentially good ideas to a followup discussion.
  5. Sample content – Kevin shared his initial thoughts and ideas for adding sample content, structure and configuration to core. More questions then answers but that’s just where we’re at for now. You are welcome to add your questions and ideas, please do.

As always, most welcome to join if you’re interested. Find us in the ux channel of the Drupal Slack room, or follow @drupalux on the twitters.

Tags: drupaluxuxmeetingdrupalplanetSub title: Topics du jour, how we work, where you can help, the usual
Categories:

Drupal Blog: Drupal 8.2, now with more outside-in

Planet Drupal - Tue, 2016/08/23 - 9:14pm

Over the weekend, Drupal 8.2 beta was released. One of the reasons why I'm so excited about this release is that it ships with "more outside-in". In an "outside-in experience", you can click anything on the page, edit its configuration in place without having to navigate to the administration back end, and watch it take effect immediately. This kind of on-the-fly editorial experience could be a game changer for Drupal's usability.

When I last discussed turning Drupal outside-in, we were still in the conceptual stages, with mockups illustrating the concepts. Since then, those designs have gone through multiple rounds of feedback from Drupal's usability team and a round of user testing led by Cheppers. This study identified some issues and provided some insights which were incorporated into subsequent designs.

Two policy changes we introduced in Drupal 8—semantic versioning and experimental modules—have fundamentally changed Drupal's innovation model starting with Drupal 8. I should write a longer blog post about this, but the net result of those two changes is ongoing improvements with an easy upgrade path. In this case, it enabled us to add outside-in experiences to Drupal 8.2 instead of having to wait for Drupal 9. The authoring experience improvements we made in Drupal 8 are well-received, but that doesn't mean we are done. It's exciting that we can move much faster on making Drupal easier to use.

In-place block configuration

As you can see from the image below, Drupal 8.2 adds the ability to trigger "Edit" mode, which currently highlights all blocks on the page. Clicking on one — in this case, the block with the site's name — pops out a new tray or sidebar. A content creator can change the site name directly from the tray, without having to navigate through Drupal's administrative interface to theme settings as they would have to in Drupal 7 and Drupal 8.1.

Making adjustments to menus

In the second image, the pattern is applied to a menu block. You can make adjustments to the menu right from the new tray instead of having to navigate to the back end. Here the content creator changes the order of the menu links (moving "About us" after "Contact") and toggles the "Team" menu item from hidden to visible.

In-context block placement

In Drupal 8.1 and prior, placing a new block on the page required navigating away from your front end into the administrative back end and noting the available regions. Once you discover where to go to add a block, which can in itself be a challenge, you'll have to learn about the different regions, and some trial and error might be required to place a block exactly where you want it to go.

Starting in Drupal 8.2, content creators can now just click "Place block" without navigating to a different page and knowing about available regions ahead of time. Clicking "Place block" will highlight the different possible locations for a block to be placed in.

Next steps

These improvements are currently tagged "experimental". This means that anyone who downloads Drupal 8.2 can test these changes and provide feedback. It also means that we aren't quite satisfied with these changes yet and that you should expect to see this functionality improve between now and 8.2.0's release, and even after the Drupal 8.2.0 release.

As you probably noticed, things still look pretty raw in places; as an example, the forms in the tray are exposing too many visual details. There is more work to do to bring this functionality to the level of the designs. We're focused on improving that, as well as the underlying architecture and accessibility. Once we feel good about how it all works and looks, we'll remove the experimental label.

We deliberately postponed most of the design work to focus on introducing the fundamental concepts and patterns. That was an important first step. We wanted to enable Drupal developers to start experimenting with the outside-in pattern in Drupal 8.2. As part of that, we'll have to determine how this new pattern will apply broadly to Drupal core and the many contributed modules that would leverage it. Our hope is that once the outside-in work is stable and no longer experimental, it will trickle down to every Drupal module. At that point we can all work together, in parallel, on making Drupal much easier to use.

Users have proven time and again in usability studies to be extremely "preview-driven", so the ability to make quick configuration changes right from their front end, without becoming an expert in Drupal's information architecture, could be revolutionary for Drupal.

If you'd like to help get these features to stable release faster, please join us in the outside-in roadmap issue.

Thank you

I'd also like to thank everyone who contributed to these features and reviewed them, including Bojhanyoroypwolaninandrewmacphersongtamaspetycompzsofimajor,SKAUGHTnod_effulgentsiaWim Leerscatchalexpott, and xjm.

And finally, a special thank you to Acquia's outside-in team for driving most of the design and implementation: tkolearywebchicktedbowGábor Hojtsytim.plunkett, and drpal.

Acquia's outside-in team celebrating that the outside-in patch was committed to Drupal 8.2 beta. Go team!

Categories:

myDropWizard.com: Survey Results From "Is Drupal Hard?"

Planet Drupal - Tue, 2016/08/23 - 2:51pm

A few weeks ago, we had A Survey! Is Drupal Hard?

First of all, thank you for taking the time to answer (even though we had a short-lived technical snafu!). At myDropWizard, we believe in transparency and openness, so I'm going to share the unfiltered data with you - as well as what my thoughts are in interpreting this non-scientific study.

The Data

Some Issues

  1. Many of those answering would be biased towards Drupal
  2. The choices were somewhat arbitrary, and no doubt some were left out
  3. There was an initial bug in the survey keeping some good data out
  4. The choice "It's about what I would expect" is probably better labeled as something more along the lines of "an average web developer should be able to accomplish their needs in a reasonable amount of time"
Analysis

So, there were plenty of flaws in the data, but that won't keep me from drawing a few conclusions - and I'm anxious to hear what others feel as well.

Drupal 7 Still a Favorite

"0" respondents claimed it "impossible" to do complex things while coupled with the lowest number of "Never Used It / No Opinion" at 5.

Categories:

clemens-tolboom opened issue aegir-project/development#7

On github - Tue, 2016/08/23 - 2:27pm
Aug 23, 2016 clemens-tolboom opened issue aegir-project/development#7 prepare.sh should check for a docker deamon

Nuvole: Maintain local development configuration with Configuration Split

Planet Drupal - Tue, 2016/08/23 - 2:21pm
Answering the most commonly asked question about Configuration Management in Drupal 8; and a preview of our DrupalCon training.

This post is an excerpt from the topics covered by our DrupalCon Dublin training: Drupal 8 Development - Workflows and Tools.

For the last two years we have been giving trainings and presentations at various Drupal events about configuration management and its new workflows in Drupal 8. One of the recurring questions has been:

How do I keep some configuration from being deployed? For example the devel module and its configuration?

Until now we have answered to use drush with the --skip-modules flag and then to gitignore the configuration for devel. But then you can't share the development configuration and the process is error prone when there are more modules and other configuration items that depend on the configuration you gitignore.

For some simpler cases where configuration needs to be different between environments (for example the error verbosity) the configuration override system allows to override the configuration in settings.php. This is a solution for some cases, however, you can not override which modules are enabled or override configuration that doesn't exist.

Enter: Configuration split!

Our new module Configuration split splits the configuration when exporting it with a special Drupal Console command. It can be configured to split out enabled modules and given blacklisted configuration and it will then separate all the configuration that is dependent on the listed modules or configuration. The module's settings also allow to set a folder to which the separated configuration will be exported to.

That way the configuration set which you use to deploy configuration between different environments is a subset of your development configuration and the trusty configuration system of Drupal 8 can be used unharmed. Of course when importing with the special command the split configuration is merged back, allowing you to keep your development configuration in place.

"To split" is a synonym for "to break" and as such "Configuration split" has a dangerous ring to it. This is on purpose because the exported subset is on purpose not what you have on your development site and not what you have locally tested. So you need to compensate that with a workflow that imports and verifies the configuration you are going to deploy. This is better than to import and export individual configuration because Drupal needs the whole set of configuration to do its checks.

How do I use it?

Download and enable the Configuration split module like any other module. Then configure it under admin/config/development/configuration/config_split. Set the split folder to a different folder than your normal config sync folder. If you want a prettier interface, consider using Chosen. Then use the Drupal Console command config_split:export and config_split:import to export and import respectively.

Let's look at the devel example from above. We typically version the configuration outside of the webroot in ../config/sync as seen by Drupal. (In the project root when starting a project with drupal-composer/drupal-project.) So the folder we specify for config_split would be ../config/dev. The module to filter would be Devel and the rest can be left empty. The devel.settings will be detected automatically. Note though that the system.menu.devel does not depend on the devel module and can not be detected automatically, but it is easy to add it to the blacklisted config and it could theoretically be deployed without breaking anything.

The config_split.settings.yml could look something like this:

folder: ../config/dev
module:
  devel: 0
theme: {  }
blacklist:
  - system.menu.devel

Finally the following command will export the configuration to the default sync directory without the devel module enabled and export the devel configuration into the dev directory.
web$ ../vendor/bin/drupal config_split:export

Now if you would import the configuration through the UI or with drush cim the devel module would be un-installed, and you can do that to see the site without its development configuration. However, If you want the development configuration to stay or become active and the devel module installed use the following command:
web$ ../vendor/bin/drupal config_split:import

How does it work internally?

We implemented a StorageWrapper that allows filters to interact with the configuration after it has been read and before it is written to the wrapped FileStorage during the import and export operation. The SplitFilter has a secondary storage and decides where to read from or write to. This is a very similar concept to what drush does with its --skip-modules flag since we will want to easily integrate this with drush in the future.

What comes next?

The module is still in an early development stage and some more additions in the scope of splitting configuration could be added. The subset without the split configuration could be verified after exporting it and we could warn the user if it couldn't be imported. Or for example we currently use only config_split.settings but if the need arises we could support multiple split configurations. Or we could add a "gray list" to ignore some configuration that exists rather than removing it when splitting, essentially making it a configuration override outside of the scope of Drupal's runtime. This could be useful when maintaining several sites that are almost the same but all have their little "special snowflake" configuration which in turn could be synchronized with the normal workflow.

It is important to understand that the configuration system of Drupal has limitations that are there for a good reason. Most of them are to ensure data integrity and robustness and reliability of the synchronisation and so on. In other words measures to protect you from accidentally breaking your site. Using tools like config_split or drush --skip-modules you circumvent some of these security and integrity checks so use them with caution.

Since the module is not required for the regular functioning of a Drupal 8 site (it can even be used to blacklist itself) it can already be used in the development process of your current projects already. Your feedback is welcome, see you in the issue queue.

Tags: Drupal PlanetDrupal 8DrupalConTrainingCode Driven Development
Categories:

clemens-tolboom opened issue aegir-project/development#6

On github - Tue, 2016/08/23 - 2:19pm
Aug 23, 2016 clemens-tolboom opened issue aegir-project/development#6 How should we debug a drupal site/hostmaster?

clemens-tolboom opened pull request aegir-project/development#5

On github - Tue, 2016/08/23 - 2:18pm
Aug 23, 2016 clemens-tolboom opened pull request aegir-project/development#5 Ignore artifact files. 1 commit with 7 additions and 0 deletions

Rakesh's DSoC 16 blog: GSoC Final Submission

Planet Drupal - Tue, 2016/08/23 - 10:59am
GSoC Final Submission rakesh Tue, 08/23/2016 - 14:29
Categories:

Dries Buytaert: Drupal 8.2, now with more outside-in

Planet Drupal - Tue, 2016/08/23 - 9:10am

Over the weekend, Drupal 8.2 beta was released. One of the reasons why I'm so excited about this release is that it ships with "more outside-in". In an "outside-in experience", you can click anything on the page, edit its configuration in place without having to navigate to the administration back end, and watch it take effect immediately. This kind of on-the-fly editorial experience could be a game changer for Drupal's usability.

When I last discussed turning Drupal outside-in, we were still in the conceptual stages, with mockups illustrating the concepts. Since then, those designs have gone through multiple rounds of feedback from Drupal's usability team and a round of user testing led by Cheppers. This study identified some issues and provided some insights which were incorporated into subsequent designs.

Two policy changes we introduced in Drupal 8 — semantic versioning and experimental modules — have fundamentally changed Drupal's innovation model starting with Drupal 8. I should write a longer blog post about this, but the net result of those two changes is ongoing improvements with an easy upgrade path. In this case, it enabled us to add outside-in experiences to Drupal 8.2 instead of having to wait for Drupal 9. The authoring experience improvements we made in Drupal 8 are well-received, but that doesn't mean we are done. It's exciting that we can move much faster on making Drupal easier to use.

In-place block configuration

As you can see from the image below, Drupal 8.2 adds the ability to trigger "Edit" mode, which currently highlights all blocks on the page. Clicking on one — in this case, the block with the site's name — pops out a new tray or sidebar. A content creator can change the site name directly from the tray, without having to navigate through Drupal's administrative interface to theme settings as they would have to in Drupal 7 and Drupal 8.1.

Making adjustments to menus

In the second image, the pattern is applied to a menu block. You can make adjustments to the menu right from the new tray instead of having to navigate to the back end. Here the content creator changes the order of the menu links (moving "About us" after "Contact") and toggles the "Team" menu item from hidden to visible.

In-context block placement

In Drupal 8.1 and prior, placing a new block on the page required navigating away from your front end into the administrative back end and noting the available regions. Once you discover where to go to add a block, which can in itself be a challenge, you'll have to learn about the different regions, and some trial and error might be required to place a block exactly where you want it to go.

Starting in Drupal 8.2, content creators can now just click "Place block" without navigating to a different page and knowing about available regions ahead of time. Clicking "Place block" will highlight the different possible locations for a block to be placed in.

Next steps

These improvements are currently tagged "experimental". This means that anyone who downloads Drupal 8.2 can test these changes and provide feedback. It also means that we aren't quite satisfied with these changes yet and that you should expect to see this functionality improve between now and 8.2.0's release, and even after the Drupal 8.2.0 release.

As you probably noticed, things still look pretty raw in places; as an example, the forms in the tray are exposing too many visual details. There is more work to do to bring this functionality to the level of the designs. We're focused on improving that, as well as the underlying architecture and accessibility. Once we feel good about how it all works and looks, we'll remove the experimental label.

We deliberately postponed most of the design work to focus on introducing the fundamental concepts and patterns. That was an important first step. We wanted to enable Drupal developers to start experimenting with the outside-in pattern in Drupal 8.2. As part of that, we'll have to determine how this new pattern will apply broadly to Drupal core and the many contributed modules that would leverage it. Our hope is that once the outside-in work is stable and no longer experimental, it will trickle down to every Drupal module. At that point we can all work together, in parallel, on making Drupal much easier to use.

Users have proven time and again in usability studies to be extremely "preview-driven", so the ability to make quick configuration changes right from their front end, without becoming an expert in Drupal's information architecture, could be revolutionary for Drupal.

If you'd like to help get these features to stable release faster, please join us in the outside-in roadmap issue.

Thank you

I'd also like to thank everyone who contributed to these features and reviewed them, including Bojhan, yoroy, pwolanin, andrewmacpherson, gtamas, petycomp, zsofimajor, SKAUGHT, nod_, effulgentsia, Wim Leers, catch, alexpott, and xjm.

And finally, a special thank you to Acquia's outside-in team for driving most of the design and implementation: tkoleary, webchick, tedbow, Gábor Hojtsy, tim.plunkett, and drpal.

Acquia's outside-in team celebrating that the outside-in patch was committed to Drupal 8.2 beta. Go team!
Categories:

Liip: Drupal 8 accessibility features

Planet Drupal - Mon, 2016/08/22 - 10:36pm

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.

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.

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.

Forms

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.

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 Closed Active

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:

Caption for the table Details for the table Description for details Title Content type Premo Quae Vero Article Capto Dolor Article

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');

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.

Conclusion

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.

Categories:

OpenLucius: 14 Cool Drupal 8 modules for site builders | August 2016

Planet Drupal - Mon, 2016/08/22 - 8:44pm

Here’s what struck me last month about Drupal modules. This month I have chosen to focus on Drupal 8 as this is slowly becoming the go-to version - partly because many required modules have been migrated and grown up.

1. Require Login
Categories: