Mar 14 2019
Mar 14

Are you concerned about web accessibility issues that might be hidden within your pages?

We recently gathered input from the Promet accessibility team concerning digital accessibility issues that are most often in need of remediation, and we came up with a Top 12 List of web accessibility mistakes and oversights. They pertain to:

1.  Alt text
2.  Color contrast
3.  Forms
4.  Headings
5.  iFrames
6.  Keyboard accessibility
7.  Landmark roles
8.  Links
9.  Lists
10. Semantic markup
11. Tables
12. File attachments

1. Alt Text

An image might be worth a thousand words, but if someone can’t see the image, then what? So, what’s up with the images on your site? Make sure that they are not missing: 

  • The alt attribute and descriptive text,
  • Enough description in the alt attribute, or 
  • A null alt attribute (alt="") indicating that the image is decorative and thus has no meaning.

If the image is a chart, alternative text that briefly describes it might not be enough. Complicated charts and graphs will require extra effort. The use of the longdesc attribute can be used if the narrative of your content doesn’t already include the information communicated by the image. 

2. Color Contrast

This one can be problematic if you’re heavily invested in your branding. If a color contrast checker reveals that your branding colors don’t create sufficient contrast, there are minor fixes you can employ to achieve accessibility. The two issues we see most often are insufficient color contrast:

  • Between text and background colors and 
  • Between text and UI components (i.e. button) or background image(s).

This type of problem can be headed off at the pass with a well-planned design and teaching your content authors how to incorporate accessibility into the creation of their colored charts and graphs.
 

3. Forms

Forms perform different duties. You have the search box on every page. That’s a form. That “Sign up for our Newsletter” on your homepage is a form. And, let’s not forget “Contact Us.” That’s three forms and we haven’t gotten to the comment forms, e-commerce forms, or event sign up forms. So, you can see, accessible forms require considerable attention.  

Now, add in the long list of issues we see to understand why your forms might be your most vulnerable objects on the page.

  • Form fields found with missing labels.
  • Form labels found with "for" attribute not matching another element’s ID.
  • Select element’s option doesn't have value available.
  • Select element doesn't have initially-selected option.
  • If this selection list contains groups of related options, they should be grouped with optgroup.
  • Checkboxes/Radio Buttons should be contained within a fieldset.
  • Fieldsets must contain a legend element.
  • Form is missing a required submit button.
  • Button elements missing value and/or content.

These are fixable offenses. For example, if your button elements are missing value and/or content, this is what that means.

Inaccessible
<input type=”submit” />

Accessible
<input type=”submit” value=”Submit Form” />

As you can see, the fix is simple. However, the tricky part can be gaining access to the site in such a way that the solution can be applied. If you’re using a third-party plug-in or a content management system, you might not have access to the code that generates your forms. 

4. Headings

Headings in HTML are defined via the <H1>, <H2>, <H3>, etc. elements. 
So often content is chunked in an article by using sub-headers styled with <strong> versus <H2>, for instance. This is not considered accessible. 

When Promet Source audits website pages, we often find:

Heading tags without content, and 
Heading structure that is not logically nested.

What does logically nested mean? Let’s take a look.

Inaccessible 
<h1>About Us</h1>
<h4>Our History</h4>
<h6>Our Future</h6>

Accessible
<h1>About Us</h1>
<h2>Our History</h2>
<h2>Our Future</h2>

This example makes it look like the content is the problem and it might be. However, this kind of issue can creep up in the presentation of page objects that reside outside the main content. 

5. iFrames

iFrames are used to display content on your web page from an external source. In this scenario, you need to think about two things: the iFrame on your page and the external content source, or third-party.

Start with ensuring your iFrame has a title, as shown in the sample code below. Then, ensure that the external content is accessible, which might not be easy if you don’t have an agreement with the source to provide accessible content. Remember, just because it came from someone else, that doesn't mean you are responsible.

Inaccessible
<iframe src=”/images/maine-beach-home.png” width=”...” height=”...” />

Accessible
<iframe title=”Maine beach home” src=”/images/maine-beach-home.png” width=”...” height=”...” />

6. Keyboard Accessibility

You scroll the browser window to see what’s hidden below. You place your cursor on a link or in a form field using your touchpad or mouse. Swiping and screen taps have become actions we take for granted on mobile devices. What would you do if you couldn't click or tap?

The most common keyboard accessibility issues we see are:

Elements that are not keyboard accessible;
Elements that are not visible when it gets focus (e.g., show a dotted border); and 
Forms that cannot be navigated using the keyboard and other accessibility tools. (i.e. accordions).

Let’s consider the first issue. Helping a user navigate to non-link and non-form elements is often overlooked. If your page is divided into sections, allowing the user to tab through the sections can be helpful.

Inaccessible
<div>Complementary content region</div>

Accessible
<div tabindex=”0”>Complementary content region</div>

7. Landmark Roles

So far we’ve talked about aspects of web pages that you are likely aware. This next topic has to do with the W3C’s Accessible Rich Internet Applications Suite (ARIA), and the roles and attributes that you can assign to your HTML elements. 

The W3C says, “With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities.” However, it can also create issues if you apply ARIA’s roles and attributes incorrectly. For instance:

  • Elements missing required landmark roles, and 
  • Landmark role "presentation" is applied improperly on an element because its child elements contain semantic meaning.

Let’s consider the application of roles and semantic meaning.

Inaccessible
<div class=”promet-logo” role=”presentation”>
    <img src=”/images/promet-logo.png” />
</div>

Accessible
<div class=”promet-logo”>
    <img src=”/images/promet-logo.png” />
</div>

Sometimes a role assignment makes things worse, not better.

8. Links

When it comes to accessible links, you have two perspectives to consider: code and content. Before we look at the coding issues for accessible hyperlinks, let’s consider content. 

Links such as “Click here” and “Read more” appear often on the internet, but they’re not accessible because they lack purpose. 

Imagine listening to assistive technology reading out the links on a page, “Read more. Read more. Read more.” Read more what? In order for the link to be purposeful it needs to indicate what you would be reading more about. For example: “Read More about Weather Patterns.”.

Regarding coding issues, we see five coding issues on a regular basis.

  • Anchor elements found with valid href attribute but no link content.
  • Anchor elements found with missing href attributes.
  • Broken links to 404 (page not found) pages (e.g., a link to google.co versus google.com).
  • Back to top anchor link doesn't exist.
  • “Skip to main content” link is missing.

The ‘skip to main content’ link accommodates success criterion 2.4.1 Bypass blocks, enabling a user of the page to bypass listening to the menu and any other blocks of content that stand in the way of them hearing the main content. Below is some code that illustrates the problem.

Inaccessible
<body>
     <header></header>
     <main id=”main-content”></main>
</body>
     <a id=”skip-link”>Main Content</a>

      Accessible
<body>
    <a href=”main-content” id=”skip-link”>Skip to Main Content</a>
<header></header>
<main id=”main-content”></main>
</body>
 

9. Lists

f you are familiar with HTML, you might find it hard to believe that bulleted lists are, at times, not created using the <ul> and <li> elements. Just because a list visually appears as such, that doesn’t mean assistive technology will read as that way.

So, remember that:

  • List elements should be marked up as a navigation list, and 
  • Ordered/unordered/definition lists should include list items.

What do we mean by “should include list items?” See the example below.

Inaccessible
<ol>
     <div>Link 1</div>
     <div>Link 2</div>
     <div>Link 3</div>
</ol>

Accessible
<ol>
     <li>Link 1</li>
     <li>Link 2</li>
     <li>Link 3</li>
</ol>
 

10. Semantic Markup

Semantic markup has to do with meaning. If something is a paragraph, use <p>, not <span> or <div>, for instance. Other examples include <form>, <table>, and <article>. These HTML elements are descriptive and carry meaning. Semantic html matters.

We often see:

Duplicate ID attribute values found on pages, and
Semantic markup used for emphasis or special test (i.e. don’t use <font>).

Let’s take a look at the ID attribute that can be assigned to an HTML element. In this example, a web page has three unique forms and they each have the same ID. 

Accessible
<form id=”search”>
<form id=”search”>
<form id=”search”>

Inaccessible
<form id=”search-header”>
<form id=”search-content”>
<form id=”search-footer”>

The ease with which such fixes can be applied rely on how your website is created and if you have access to the code.
 

11. Tables

Tables are not as responsive as you will need them to be. So, if you don’t need to use a table, don’t. If you need to use a table, note that the following accessibility issues are often found.

  • Table is missing caption elements.
  • Table headers are missing the <th> element.
  • The relationship between <td> elements and their associated <th> elements is not defined.

The last example is easy for content authors to overlook as HTML editor buttons do not insert ID and header attributes. Notice how the data cell references the table header cell that is applicable.

Inaccessible
<table>
    <thead>
        <th>One</th>
<th>Two</th>
<th>Three</th>
</thead>
<tbody>
    <td>Column 1 content</td>
<td>Column 2 content</td>
<td>Column 3 content</td>
</tbody>
</table>

Accessible
<table>
    <thead>
        <th id=”col1” headers=”blank” scope=”col”>One</th>
<th id=”col2” headers=”blank” scope=”col”>Two</th>
<th id=”col3” headers=”blank” scope=”col”>Three</th>
</thead>
<tbody>
    <td headers=”col1” scope=”row”>Column 1 content</td>
<td headers=”col2”>Column 2 content</td>
<td headers=”col3”>Column 3 content</td>
</tbody>
</table>

12. File Attachments

Accessibility is not just about the HTML page. PDFs are commonly uploaded to a page for purposes of download. They, and other files such as MS Word and Powerpoint files, are required to be accessible.

PDF accessibility requirements that we see most often pertain to the following issues:

  • Untagged content,
  • Missing alternative text for images, and
  • Incorrect reading order.

The process to fix non-web files varies, depending on the source document. 

Conclusion

As the above examples demonstrate, accessibility compliance calls for close attention to a wide range of details.

One of the most challenging aspects of making a site accessible tends to be of fixing the technology used to create it. If your site was created from individual HTML pages, you can edit the markup and fix many, if not all of your issues. If not, a site rebuild might be in order.

Before you build a new site, make sure that the content management system is designed to produce accessible pages and forms. It’s also essential that you audit your current pages to identify accessibility issues before they are migrated into the new site. 

Promet Source offers a path to achieving accessibility compliance for your websites, web applications and technical products. With flexible testing and remediation options, we can partner with you to ensure that you are adhering to WCAG 2.1 guidelines.  

Contact us today for a conversation on the level of training or support that best fits your needs.

Feb 27 2019
Feb 27

With the increased number of accessibility lawsuits for inaccessible websites, it's no wonder that offers for quick fixes are a hot commodity. Unfortunately, the saying, “You get what you pay for” may not apply to accessibility overlay solutions.

So, what do you do? First, let’s take look at how quick-fix web accessibility overlay solutions actually work.

 

What are Web Accessibility Overlays?

Imagine your HTML web page on your web server. It can be an actual HTML file or a cached version of the page that your content management system creates on your behalf. Now, imagine a Javascript being added to the file and that script makes changes to the HTML rendered in that HTML file.

Tada! That Javascript change is the fix you need and your web page is now accessible. Or, is it? That depends.

  • It depends on what’s wrong on your page.
  • It depends on whether a Javascript can actually fix the issue.
  • It depends on whether the cached HTML page has changed and if the Javascript still works.

 

Are Accessibility Overlays for You?

With all the depends-on-this and depends-on-that scenarios that can come up, we can’t say definitively one way or the other. Therefore, we are going to walk you through a process where you can decide what’s best for your site.

The following four-step process sounds simple, but in the long run, it might not be. We’re sorry, but it’s the nature of the beast.

  1. Find the issue.
  2. Identify the required fix.
  3. Implement a solution.
  4. Test the solution.

1. Find the Issue.

The short description of this step is to conduct an audit, using both automated tools and manual testing. If you don’t have the in-house skills to identify all your potential issues, Promet Source is here to help. 

Common web page accessibility issues that can be caught by automated testing include:

  • Missing Alt text for images
  • Insufficient color contrast
  • Label issues in your forms (there are other types of form issues as well)
  • Incorrect application of headings
  • Missing titles for iFrames
  • HTML elements are missing landmark roles
     

Other issues that are better identified with manual testing include:

  • Insufficient alternative text for images
  • Lists that are not coded as lists
  • Attached non-web content, such as PDFs, are not accessible for one or many reasons
  • Missing media captions and/or transcripts

2. Identify the Required Fix.

So, how do you fix the issues? As you can imagine, given the list above, not all fixes are code based. Let’s look at a few examples.

  • Missing Alt text. It takes a human to see an image and describe it. You would need a Javascript that could apply all the unique descriptions that are missing. 
  • Label issues in forms. Given there are numerous issues associated with this topic, you would need a Javascript for each type of issue. Of course, like Alt text, some labeling requires a human decision as to which fix renders the correct solution.
  • Keyboard focus not visible. In order to see where a user’s tab key has landed, the object needs to change. For example, a border is applied. Borders are managed in the CSS files, not the HTML file. You would need a Javascript that could apply an inline style of your choosing for each tab-able object on the page.

3. Implement a Solution.

Fix the source code or go with an Accessible Overlay solution. This is where a couple more “depends” questions come into play.

  • Depends on whether the cost to locate and configure the Javascripts to fix your pages’ issues is less than the cost to fix the source.
  • Depends on your plans for updating your site.

And, let’s not forget the “depends” questions already asked. Is there a Javascript solution for your issue? If not, fixing the source code might be your only option. 

This is where things can get complicated. Not all systems allow you access to resolve the issue. Therefore, you might have to switch to a system that supports accessibility or allows you to make the appropriate changes.

4. Test the Solution.

Just because a Javascript solution looks like it will work, that doesn’t mean you don’t have to test it. Remember, if your site is running off of a content management system, you might find that the cached HTML page that gets “fixed” by the overlay solution, no longer has the exact same broken code as it did a few hours ago.

So, test, test, test. And then, keep watch. 

Next, remember that new accessibility issues can creep up over time. For instance:

  • Content author introduces a data table in a blog post that is not accessible.
  • Functionality from an external source changes, and not for the good.
  • A security patch is applied and it’s just enough to confuse the overlay you have in place.

Continued monitoring is a must when dealing with quick-fix solutions.

 

Conclusion

Accessibility overlays can serve a purpose. However, before you commit to an overlay solution, perform a cost-benefit analysis. 

  • Is the cost of obtaining a quick fix higher or lower than the cost to fix the source? 
  • Is the cost of monitoring and reapplying the overlay solution less costly than fixing the source? 
  • Is the cost of a lawsuit for an inaccessible page, where your overlay solution has stopped working, worth the quick fix?

At Promet Source, we are serious and passionate about accessibility. We’re here to help you evaluate your options and make decisions that are sustainable and strategically sound. Contact us today 
 

Feb 14 2019
Feb 14

A commercial came on the radio recently advertising a software application that would, basically, revolutionize data management and enable employees to be more efficient. My first thought was, “How can they possibly promise that when they don’t know their customers’ data management processes?” Then, it became clear. The business processes would have to be changed in order to accommodate the software.

Is that appropriate? Is it right that an organization should be required to change the way it conducts business in order to implement a software application? 

Sometimes yes. Sometimes no. 

The following four factors can serve as an essential guide for evaluating the need for change and ensuring a successful transition to a new solution. 

  1. Process Analysis
  2. Process Improvement
  3. Process Support
  4. Change Management

1. Process Analysis

Before committing to the latest and greatest software that promises to revolutionize the way you do business, make sure you’ve already documented current processes and have a clear understanding of what’s working well and what can be improved. Over the last few decades, several methodologies have been created and used to analyze and improve processes. Key among them: Six Sigma, Lean Manufacturing, and Total Quality Management (TQM).

How to Streamline Process Analysis

In simple terms, document the way you create, edit, and manage your data. Task-by-task, step-by-step, what does your team do to get the job done? If you see a problem with a process, keep documenting. Improvements, changes, redesigns come in the next step.

Steps to Document Processes

At the core of all process documentation is the process flowchart: an illustration with various boxes and decision diamonds connected with arrows from one step to the next. Collect as much data and as many contingencies as possible to make this flowchart as meaningful and robust as possible.

Diving Deeper

Integrated Definition (IDEF) methods look at more than just the steps taken to complete a task within a process. IDEF takes the following into account:

  • Input - What is needed to complete the steps in the task? Understanding this information can highlight deficiencies and can highlight flaws in effective completion of a particular step. 
  • Output - What does the task produce? Is the outcome what it needs to be?
  • Mechanisms - What tools are needed to perform the steps in the task? Can new technology make a difference?
  • Controls - What ensures that the steps within the task are being performed correctly?

Swimlane or Functional Flowcharts

In addition to the four items from IDEF data, knowing who performs a task is also important. As you draw the boxes and connect them with arrows, place them in a lane that represents the “Who” of process. Knowing who does what can reveal possible over-tasking and/or bottleneck issues in production and efficiency.

Getting Started

Whiteboards and Post-it can be an easy place to start process documentation. With today’s high definition smartphone cameras, you can sketch flowcharts, take a picture, and then share with stakeholders for their review and input. Once you have collected all relevant information, tools such as Visio or Lucidchart can make complicated process flows easier to create and visualize. 

2. Process Improvement

When you know how your current processes are performed, you can start to make improvements--whether incremental or a complete redesign (A.K.A reengineering). 

Low-hanging Fruit

Some needed improvements will likely be obvious. For example, someone on the process team says, “I didn’t know that you were doing that? I do it, too.” Duplication of effort doesn’t require metrics to be collected to determine that steps can be taken to enhance efficiency.

However, most processes require some form of metric collection to determine where improvements can be made. Metrics can include research costs, development time frames, quality assurance oversights, or frequency of downtime.

Knowing What to Change

If the needed improvement isn’t obvious, metrics can help guide the decision-making process. For example, how much time does it take to complete a process today? Could that be improved? Brainstorm ideas on how to shorten the time. Test the change and remeasure. 

Too often, data is collected with the intent of measuring the success of the process, but the data being collected is does not reflect objectives. For example, if the goal of a website or a particular page is to teach, metrics concerning the number of page visits does not indicate the degree to which that goal is being achieved. A more telling metric would be the amount of time a visitor spends on the lesson pages. Even more revealing would be the number of quizzes passed after a visitor engaged with the lessons.  

Before choosing metrics to be collected, understand your goal, determine the level of improvement you want to see, then start measuring that which will actually inform your goal.

3. Process Support

Key to process improvement is an analysis of how technology is can enhance productivity and efficiencies. 

For example: “We can cut three days worth of effort for three employees if we integrate the XYZ software into our process.” This kind of statement sounds like a worthy goal, assuming the cost to transition doesn’t exceed the long-term savings it can help realize. 

Calculating the Cost of Change

Open source software applications start out with a great price tag: Free. However, unless you use the application as is, there is always a cost associated with turning it into what you need. There are many more factors to consider than the upfront cost of the software. 

Costs can include:

  • Training on new processes
  • Training on the new software application acquired to support the new process
  • A drop in productivity and efficiency until the new process/application is adopted and accepted by your staff
  • Technology needed to support the new application
  • Keep in mind: The list of ancillary costs that are involved in the transition are unlikely to appear at the top of the salesperson’s brochure.

Return on Investment

ROI assessments will vary. Two values are needed to make this computation: cost and benefits. 

Once you've computed the short-term and long-term costs, you need to determine the benefits you gain. In a situation where investment directly translates into profit, this calculation can be straightforward.

However, sometimes the benefits are cost savings: “We used to spend this. Now we spend that.” When this is the case, instead of a cost/benefit ratio, a breakdown calculation might be required to determine how long it will take to recoup costs. 

The most complicated analysis will result from benefits such as an increase in customer satisfaction in which the benefit does not have a direct monetary value.

4. Change Management

When a team cannot see the benefit or resists change, new initiatives face an uphill battle. That’s why circling back to the process analysis phase and ensuring the buy-in of those who are being counted on to use the new application is a critical success factor.

Keep in mind that employees may not have access to the big-picture business goals that management sees, but change has the greatest chance of being realized if those who will be required to support it are informed as to why it needs to happen and included, at some level, in the decision-making process. 

Indeed, change management doesn’t start when the new application is ready to be implemented. Change management starts when:

  • All the costs of change are considered;
  • The full scope of process changes are identified;
  • Training is planned and delivered; and 
  • The campaign for change acceptance is designed and initiated.

Conclusion

You might be the boss. You might believe that the software application just discovered is what  your company or your department needs. As much as that matters, you need buy in. You need the support of the people who make your business possible. You also need to engage in a disciplined analysis of the processes that will be impacted, along with anticipated improvements and the level of support that will be deployed.

From ensuring that clients’ entire online presence is compliant with ADA accessibility guidelines to web solutions that optimize impact in the ever-evolving digital environment, we at Promet Source serve as a powerful source of transformative digital possibilities. Contact us today to learn what we can do for you.

Jan 23 2019
Jan 23

Besides Title, the most common field label found on a content type form is Body. Of course, this is where you place the body of your content. It’s your blog post, your how-to instructions, or maybe an event description. You know exactly what needs to be provided in this field because you are the trained author. What happens when the scenario includes many authors with varied skills?

Without clearly visible instructions for the form and the form fields, content authors can make mistakes. There are four default features in Drupal 8 that provide instructions for content authors.

Help

Body field configuration interface

When configuring a field, all fields except Title, you can include help text. The help text appears under the field, just like you see here on the configuration form where the help text for the help text field says, “Instruction to present to the user below this field on the editing form.”

Pros

The label of a field might not communicate the full intent or purpose of the field, so adding instructions in the help field can go a long way to ensuring an author uses the field correctly. 

For example, the Tags field on the Article content type provides default help text: Enter a comma-separated list. For example: Amsterdam, Mexico City, "Cleveland, Ohio" This provides instructions for entering tags correctly. 

However, if you need to add additional instruction regarding the context of the tags, you can include a statement like, “Do not use terms already offered in the Topics field.” 

Cons

The common placement of instructions below a field isn’t always noticeable. For example, the screenshot below shows the body field with help text below. Is it eye catching? Obvious?

Body field on the Add node page.

The size of a field can make providing easy to see instructions a challenge. And, if you need to make an accessible content type, the help text feature needs a little work to make it WCAG compliant. 

Placeholder

Configuration options for Body field on the Manage form display

Using placeholder text inside the field is another option. Although this feature is not available for all field types, it does enable you to include 128 characters of instructions. Located on the Manage Form Display tab for the content type, it’s just one configuration option available.

Pros

As mentioned in the Help section above, the Title field doesn’t have a help text option. However, the placeholder feature is available to provide tips on title strategies. Or, if the instruction is short and simple, such as a date format of MM/DD/YYYY can help users quickly understand the sequence of the date parts.

Cons

It’s only 128 characters and if the field size is less that that, not all of the instructions will be visible. On the topic of visibility, the Placeholder feature is not read by a screen reader. And, unless you do some browser specific CSS overrides, the contrast of Placeholder text might not meet WCAG color contrast criterion.

Lastly, when a user clicks in the field to enter data, the placeholder text disappears.  

Default Values

Body field default content configuration interface

The default value feature for fields is a great way to speed up data entry when the same entry is expected frequently. However, it can also be used to communicate instructions to the content author. You can go as far as providing a content template where the appropriate formatting has already been applied. 

Pros

Uniformity. Clarity. An experienced author will have their own way of conveying their thoughts, but that way isn’t always what’s best for an organization. Or, a newbie writer might need a little help to get started.

Notice the instructions for the often forgotten Summary feature. If you require a summary, include instructions like those shown in the example above and the Summary field will be open and ready when the content author uses the content type.

Also, unlike the Placeholder option, clicking in the field does not make the instructions disappear. 

Cons

The content author needs to remember to delete the instruction text. A small price to pay.

Content Type Explanation/Guidelines

Submission field settings for the content type

According to the Form Instructions tutorial provided by W3C, “Where relevant, provide overall instructions that apply to the entire form.” Each content type has the option to include a form explanation or submission guideline, as the field label suggests. 

Pros

Content add form with submission guidelines sample text.

The form explanation appears just above the Title field and outside the <form> element, which is needed for accessibility. You can also include HTML elements to format your instructions. 

Cons

If you need to format your form instructions, you will need to enter your own HTML as there is no HTML editor bar.

Conclusion

Not all forms are self-explanatory. Not all field purposes can be easily deduced. Drupal provides several options for providing guidance to your content authors, each with their own pros and cons. 

As you plan the way your finished content will be presented to site visitors, remember to plan your content type forms. Just because a content author receives training when the site is delivered, that doesn’t mean they will remember everything they learned. Form instructions help.
 

Dec 19 2018
Dec 19

Imagine if you will, you have an Events link on your main menu. Someone clicks on it and the Events landing page is loaded in their browser. How was this page built? With Drupal, you have several options. 

If you are the kind of person who likes to have a say in the way things are done, be it from a previous bad experience or idle curiosity, the following will help you engage in the planning aspects of your Drupal site. So, let’s look at five recipes for building landing pages in Drupal.

  • Node page
  • Node Plus View Block
  • A View Page Plus a Block
  • Panel Page
  • Custom Theme Page

Node Page

Content pages in Drupal are called nodes. You fill out a form (e.g., a content type) online, save, and you have an article or event or some other kind of page. This page has a URL. That’s important to remember. Every page in a website has to have a URL. 

How

Using Drupal’s default Basic Page content type, you fill out the form. Give the page a title of About Us. Fill in the body field with information about you or your company. Add it to the main navigation menu with a check of a box. Lastly, you create an URL alias. Instead of the default format of /node/3, you want /about-us. Save and you see your new landing page.

Yes, it’s boring, but we’re just getting warmed up. 

Why

Simple page. Simple technique. Easy to create and edit. Easy to translate in a multilingual site. And let’s not forget the other cool things you can do with a node.

Node Plus a View

Building on the previous example, let’s build an Events landing page. Obviously, this kind of page is going to be a little more complicated. Here are the requirements: a title, some introductory text, and a list of Events that you created using an Events content type. You will have many events so using a manual approach to creating and updating a list of events is not a fun idea.

How

With this scenario, you use the Basic Page content type and create a node titled Events. Using the body field, you add some text that describes your events. Like before, check the box to add this node to the main navigation. Give your page the URL alias of /events. Save and the first part of the configuration is complete.

The next step in the configuration process is a little more complicated, but it’s the concepts you need, not the details at this time.

Drupal has a module called Views. It’s an incredible tool that lets you create an SQL query on the database and then create a display for the results of that query. For this landing page, you need events for the future, not the past, so you filter accordingly.

Given we already have a Drupal feature with its own URL (the event node), we don’t need another. That means you will create a block display for the SQL query results. Blocks can be small bits of information or larger, more complicated displays. They can even hold forms. What they don’t have is a URL. They only show up because a page is there to host them.

Without going into all the particulars, you will place the block so it appears under the body field. If you want to know more about how this done, please join us in a Drupal 8 Site Building Best Practice training class.

When you go to the yoursitename.com/events URL, you will see the Events node and the view block that lists the upcoming events. With some styling, you can make the two features (node and view) appear as one, seamless page.

Why

Some will argue that you could have made a View page versus using this two-step process. And, in the next example, you will. In this scenario, you looked ahead and saw that the introduction text would not be a fixed blurb. You will change it from one season to another and your staff will not have the skills to edit a View.

So, this scenario worked nicely for your business process and staff.

A View Page Plus a Block

Let’s change up the requirements as a means of introducing another build option. You need a list of events, but instead of some introduction text, you need an image banner. There are several ways to accommodate this new image requirement, including adding to the previous scenario. In this example, we will use a View page and a block.

How

Create an SQL query, grabbing all the events scheduled for the future. Instead of displaying the list of events in a block, you create a page with a URL of /events and place it on the main navigation menu.

Next, create the block that will display your image banner. Like with most requirements, Drupal provides several alternatives to meeting them. For this scenario, assuming you are using Drupal 8, create a new block type called Image Banner. Add an image field to the new block form and set the field display to show only the image.

Create a block, using your new block type. Upload the image you need for the Events landing page. This process is very similar to creating a node. The input form looks similar as well. 

Place the banner image block either above or below the page title block to match your design. This is a quick and easy way to insert an image above the title of the page if that is your choice. 

Why

A View page isn’t like a node. It doesn’t have fields. You can add a header and footer text, but it’s not the same as adding a field to a node. Bottom line, a View show the results of a query - typically that of nodes. So, if you need to display information other than the query results, you might need to use methods like described above, by adding blocks or combining a node with a view.

Another reason for mixing and matching features to create a landing page is display. By default, a Drupal page - node or view - is broken into two parts: Title block and Main Page Content block. If we had chosen to add an image to the available header text box in the view, the image would appear below the page title. Yes, you can do some template coding and rearrange things a bit, but why would you if you could simply place a block and accomplish the same goal.

The point of all this is, remember that content comes in parts in the Drupal world, and quite often, a simple mix and match strategy is all that needed.

Taxonomy View Page

A technique that can be overlooked is the use of the default taxonomy term page. A term is a word or phrase used to describe the content in the node. By default, a term page displays when someone clicks on a term link shown on a node. The page provides a list of nodes tagged with that term. 

Let’s see how this default feature might be used to create landing pages by changing our focus from Events to types of content.

How

Imagine that you have three types of content that will be placed in a body field: How-to Lessons, News, and Blogs. Instead of creating three separate content type forms, you add a field that assigns terms to the content, declaring it a How-to Lesson, for instance.

By default, the How-to Lesson term has its own landing page. In Drupal 8, the term page is a View page and can be modified to meet your display layout needs.

Let’s take this scenario one step further. It’s come to your attention that you need a banner image and introduction text to appear above the list of nodes tagged as How-to Lesson. In this scenario, you can add an image field to the term and use the description field for your introduction text.

The results are very similar to what we have created in the previous scenarios: a page title, and image, some text, and a list of nodes. Place the page URL on the main menu and you have a landing page. 

Hopefully, this demonstrates the need to think about your processes before choosing a configuration strategy. There are several steps involved but it’s actually quite easy to learn how to do in a Drupal training class.

Why

Websites can be complex and that might mean multiple content types. However, imagine that one of your staff is blogging the latest insight on gardening strategies and it morphs into a how-to lesson. If they created the blog post in the Blog content type, they would need to move that content to the How-to Lesson content type instead. 

If this is something that might happen, create one content type for narrative content and use terms to distinguish between them. If you do, you can then take advantage of the term’s default pages, as demonstrated in this example.

Panel Page

So far, our examples assumed simple displays. What if you want to create a landing page whose content is built solely from blocks. Basic text blocks. View blocks. Blocks from other modules. Again, there are several ways to make this happen, especially if your theme (that bundle of code that controls the look and layout of your site) has the appropriate regions to organize your blocks in the way you need.

For now, let’s assume you need something unique.

How

Panels is a module that you can add to Drupal. It provides a graphic user interface (GUI) and allows you to create a page with its own URL that can be assigned to the main menu. Remember, if you need a page in Drupal, it has to come from something that can have its own URL. You can also create a custom layout to display blocks.

The process to complete this task is too complicated to step through here, but it can be learned in a Drupal training class.

Why

Some will say that you should create the theme regions you need versus using Panels, and they would have a valid point. However, if by now you are intrigued with the build process and are wondering if you might be able to do it yourself, then a tool such as Panels doesn’t require you to know how to customize a theme. 

Of course, with training, a custom theme is something you can manage. In fact, let’s consider one way of using a custom theme to create a page on your site.

Custom Theme Page

Let’s take a moment to consider the Drupal theme. Without going into all the details of theme development, at a minimum, you need to know that the theme defines the regions (header, navigation, sidebars, content, footer, and more) used to organize and display blocks. It also manages the templates used to say what gets rendered in the region.

For example, there is a page template. This renders the region if there is a block assigned to show in said region. You can add as many regions you want in order to accommodate the various block layouts you need.

You can also create a template for a single page. Let’s consider this strategy for a moment. 

How

Assume that you created a node using the Basic Page content type and titled it Resources. In the theme, you create a template specific to this node. At this point, it’s all about hand coding. You create a template that renders all the blocks you have created to display on this page. Then, with some CSS, you style the blocks in a layout of your choosing.

With the Resources node assigned to the main navigation menu,  you have the page you need because its custom template is hard coded.

Why

To be honest, although this blogger has seen this approach used, it is not conducive to making quick changes to the page. Why is it listed as an option? Because, depending on who you hire to create your site, you might end up with a vendor that uses this technique. Be it on purpose to gain maintenance business from you or just from lack of Drupal building experience, you could end up with a site that does not take advantage of Drupal’s flexibility.

Make sure you are specific in your requirements regarding the use of custom code if this is a concern.

Planning and Promet

The five options conveyed here are not the only options you have available. Moving forward, consider taking an active role in the development strategies chosen to create your site to ensure you receive a solution you can manage. 

Remember to build in time in your schedule to have development strategies discussed before they are implemented. If your developer is reluctant to let you in on their plans for meeting your requirements, they might not be the vendor for you. 

If you still have questions, check out Drupal 8 Makes it Easier and The Path to Migration to learn more about your options and considerations for your project.

Promet offers a unique planning engagement that we call our Architecture Workshop. This workshop is a customized engagement that engages all of your stakeholders in the Discovery Process. We do a 3-5 days of intensive onsite exercises with stakeholders (for your busy C-level folks we customize the agenda to bring them in where they are needed during this onsite). Then the team goes away and produces a set of deliverables that includes a full-field level Architecture Blueprint of the website(s). Whether you choose to use a waterfall or agile development methodologies - you have everything you need to build the website everyone has agreed upon. 

Not building your site and stressed out about getting an accurate quote? Investing in this kind of Workshop will make sure that you get the right Partner, and the best price.

For more planning information email [email protected].

Nov 15 2018
Nov 15

Did someone test your website for accessibility conformance without your knowledge and then inform you that your organization is prime for an accessibility lawsuit? Are they offering to help you fix the issues found on your website? 

That notification and offer might be valid, but it also might not be the entire picture. One free test grade might not reflect how your site is doing in all its accessibility subjects because automated testing tools can't find all the problems. We believe in assessing all topics of accessibility before recommending a sit down to discuss your options on how to proceed.

How do we do it? 

We don't rely on automated testing to reveal the true nature of a website's issues. We manually test it as well. We look at what makes your website unique and try to understand its mission before creating a scorecard you can use in your decision-making process.

This card reflects several perspectives including the issues anyone with an automated testing tool can see, including you. Many are free to use and quite robust in their feedback. Give one a try. For example, Code Sniffer.

But don't stop there. Our scorecard also reflects a sample of other accessibility issues not seen by the tool.

Last but not least, we look at how you are delivering your website. This part of the review is critical to understanding whether fixing or rebuilding the site is going to be your most cost-effective solution.

Website Grade

Just like the report card you got as a kid, we use grades to convey the accuracy and quality of your work, or in this case, your website. As you can see below, there are degrees of quality: A through D. No F, for failure. We assume no site is that bad.

A – Accessible & modern platform, main issues residing solely in the content
B – Accessible & modern platform, but issues with template items such as menus, sidebars, and in-line styling
C – Accessible & modern platform, but many features need to be replaced or reworked to achieve compliance
D – Antiquated platform, non-responsive, easier to rebuild vs. fix

The Scorecard is not intended to act as a thorough report or formal recommendation, simply a high-level overview. It's our tool to facilitate a conversation with you and help you choose the best path to remediation.

For example, we might find that you are using a content management system tuned to meet the accessibility criterion, but your content developers aren't using appropriate techniques when posting. Fixing existing content issues without “fixing” the reason the issues exist just means your site will continue to have problems.

Or, the example could be far worse. We hate to say it in this day of accessibility lawsuits, but there are still platforms out there that don't follow the rules. If your site was created using an antiquated approach, it might be more cost effective to rebuild rather than create workarounds in your current system.

Our Passion

Here at Promet Source, we are passionate about accessibility. We offer an array of services and remediation options that can be shaped to fit your needs. But, be warned, we are not a quick fix/band-aid company. We believe in enabling you to move forward knowing that you have a fully accessible site and the means to keep it accessible.
 
The decision process associated with such an undertaking can feel overwhelming. That's why we offer the scorecard as part of your remediation process. It's your tool to use in helping others in your organization to understand the level of effort you are facing by moving forward. 

We find that when all stakeholders have an understanding and are vested in doing the right thing, the future of a website is easier to envision. 

We look forward to talking to you about that phone call you got by surprise or that unsolicited email full of ill tidings. Don't worry, we can help you understand and make informed decisions.
 

Nov 15 2018
Nov 15

Did someone test your website for accessibility conformance without your knowledge and then inform you that your organization is prime for an accessibility lawsuit? Are they offering to help you fix the issues found on your website? 

That notification and offer might be valid, but it also might not be the entire picture. One free test grade might not reflect how your site is doing in all its accessibility subjects because automated testing tools can't find all the problems. We believe in assessing all topics of accessibility before recommending a sit down to discuss your options on how to proceed.

How do we do it? 

We don't rely on automated testing to reveal the true nature of a website's issues. We manually test it as well. We look at what makes your website unique and try to understand its mission before creating a scorecard you can use in your decision-making process.

This card reflects several perspectives including the issues anyone with an automated testing tool can see, including you. Many are free to use and quite robust in their feedback. Give one a try. For example, Code Sniffer.

But don't stop there. Our scorecard also reflects a sample of other accessibility issues not seen by the tool.

Last but not least, we look at how you are delivering your website. This part of the review is critical to understanding whether fixing or rebuilding the site is going to be your most cost-effective solution.

Website Grade

Just like the report card you got as a kid, we use grades to convey the accuracy and quality of your work, or in this case, your website. As you can see below, there are degrees of quality: A through D. No F, for failure. We assume no site is that bad.

A – Responsive & modern platform, main issues residing solely in the content
B – Responsive & modern platform, but issues with template items such as menus, sidebars, and in-line styling
C – Responsive & modern platform, but many features need to be replaced or reworked to achieve compliance
D – Antiquated platform, non-responsive, easier to rebuild vs. fix

The Scorecard is not intended to act as a thorough report or formal recommendation, simply a high-level overview. It's our tool to facilitate a conversation with you and help you choose the best path to remediation.

For example, we might find that you are using a content management system tuned to meet the accessibility criterion, but your content developers aren't using appropriate techniques when posting. Fixing existing content issues without “fixing” the reason the issues exist just means your site will continue to have problems.

Or, the example could be far worse. We hate to say it in this day of accessibility lawsuits, but there are still platforms out there that don't follow the rules. If your site was created using an antiquated approach, it might be more cost effective to rebuild rather than create workarounds in your current system.

Our Passion

Here at Promet Source, we are passionate about accessibility. We offer an array of services and remediation options that can be shaped to fit your needs. But, be warned, we are not a quick fix/band-aid company. We believe in enabling you to move forward knowing that you have a fully accessible site and the means to keep it accessible.
 
The decision process associated with such an undertaking can feel overwhelming. That's why we offer the scorecard as part of your remediation process. It's your tool to use in helping others in your organization to understand the level of effort you are facing by moving forward. 

We find that when all stakeholders have an understanding and are vested in doing the right thing, the future of a website is easier to envision. 

We look forward to talking to you about that phone call you got by surprise or that unsolicited email full of ill tidings. Don't worry, we can help you understand and make informed decisions.

Email us for help!
 

Oct 20 2018
Oct 20

The most common way to post content on a web page is via HTML text, images, audio, and video. No matter your approach to content delivery, you probably know that your approach needs to be accessible. Did you know that non-web content such as Adobe PDF documents needs to be accessible as well?

Is your restaurant menu downloadable? Do you post your meeting agendas? What about event brochures or product catalogs? PDF files are great for such purposes and need to be accessible.

Did you know that the rules you follow to create accessible HTML content, also apply to non-web content such as Word and PDF files? You might be wondering how one makes non-web files like PDFs accessible. That’s where the Web Content Accessibility Guidelines (WCAG) comes into play. Of course, not all will apply such as Bypass Blocks and Captions for video but the WCAG criterion will be your guide. 

Let’s consider some of the guidelines that will apply to non-web documents.

Applicable WCAG Criterion

When creating documents, you need to cover the basics. 

  • Declare the document’s language.
  • Include a title for your document
  • Use Header styles instead of manually bolding a header or changing its font size
  • Ensure that said headers are orderly, that you don’t jump from header 2 to header 4, for instance
  • Include a brief description of your images via alternative text 
  • Ensure color contrast ratios are met
  • Identify the meaning of shapes and icons that you might use
  • Declare header row in any data tables you create
  • Resist the urge to use tables to manage your content layout
  • Ensure that embedded links have a clear purpose (no “Click here” links)
  • Remember not to leave inline bookmarks hanging without its partner link

The more complicated the PDF, such as those with forms, you will need to meet another criterion.  However, for your basic content document, hopefully, you are thinking that this list doesn’t sound too bad. If not, you have help. If you miss something while creating your PDF, Adobe Acrobat has an accessibility testing tool that will remind you to check things it can’t, tell you if it sees something wrong, and will give you help to fix the issues.

But, let’s not get ahead of ourselves. The first step in the process of creating the accessible PDFs.

Create a Source File

Microsoft Office, Corel, Google, and Adobe are just a sampling of product vendors whose applications can create PDF files after its user has created a source file. Perhaps you are using one of these or some other application. As long as your source file can be made to accommodate the requirements listed above before you export a PDF, then you are well on your way to creating an accessible document.

Save As or Export a PDF

If you create an MS Word document, for example, the process is to save as a PDF. If you create an InDesign document, the process is to export. Whatever the vernacular, convert your source file into a PDF.  

Convert does not mean print to PDF, nor does it mean scan to PDF. Both of these options create an image of the text. That means assistive technology cannot see the text. 

Sadly, not all conversion processes work perfectly. That means testing and repair is required.

Test and Touch up the PDF

Even if you have a simple Word document with sections and subsections divided by headers, you can still run into issues once the file has been converted to PDF. Use the accessibility testing tool in Adobe Acrobat to check for hidden issues. 

For instance, by default, the Acrobat accessibility test result will likely tell you to check your color contrast - assuming you are using color in your document. It might also say you don’t have a title when you do. FYI, the title being requested is part of the document’s metadata. Lastly, it will likely ask you to check the logical reading order of your content. 

You might think that checking the logical reading order can be ignored. You created a document whose content is presented in a logical order. How could it have possibly changed? Just to be sure, you scroll through the PDF and see that all is well. 

Logical reading order isn’t about what you see, it’s about the order assistive technology will read the content. So, be sure to click on Reading Order in the Accessibility options in Acrobat. Make sure that the numbers assigned to each item on the page convey the actual order. You would be surprised how often the reading order differs from what you see.

There could be other issues the test reveals. Don’t worry about not knowing how to fix all the issues it finds. Acrobat provides links to short tutorials that explain how to remedy an accessibility problem it has found. 

However, before you fix something in the PDF, make sure it was formatted correctly in the source of the source file. It if is not, fix it there and convert again.

Conclusion

If you have a choice between placing content on your site via a PDF versus HTML text, consider the HTML text first. HTML text is more accessible than a file that has to be downloaded. Plus it is easier to format HTML text and images to be accessible.

If faced with a multi-page source file that can’t easily be ported into HTML text, then plan ahead. Allow time to inspect your PDF’s reading order and remedy any accessibility issues before you put it online.

Not sure you have a problem? Email our Accessibility Experts - they can evaluate your site, and provide you with an Accessibility Scorecard. If you know your documents are a problem, we can estimate the cost of remediating those documents. 

Oct 18 2018
Oct 18

A web page in Drupal is made up of several parts. For instance, you have the header and navigation that appears on each page. You have the main content region that holds your articles or the details associated with your events. On either side of the content, you might have sidebars with blocks suggesting related content or a call to action. 

Typically, each part of the page is created or managed by different members of your website team. The developers that originally created your site will have set up your header and menu, for example. You might have a trained IT member of your team tasked to create and place blocks in the sidebars as needed. Then, when a content author publishes an article, those blocks appear as planned on the article.

A setup like this taxes your IT team and limits your content authors. Let’s explore how content types, fields, and views can empower your authors to influence the block that appears in the sidebars from article to article.

Planning Your Blocks

A simple exercise in the planning process is to ask the question, when X-type of content is published, what blocks should also appear? Traditionally, this would mean a fixed set of blocks configured to be visible on that content type or based on the URL alias.

But, what if you need a more granular approach to creating and enabling blocks? What if you wanted your content author to create and enable blocks without having to train them to be a Drupal builder?

Let’s explore an example scenario where you list all the blocks you might need from one article post to another:

  • More like this
  • Related training
  • Call to action
  • Archive
  • Guest speakers

A few of these blocks can be set up during development to activate automatically. For example, if the article is tagged as a container garden, then other articles tagged as such will appear in a "More Like This" block. But what about Calls to Action? Let’s take a closer look at those blocks that can’t be predicted with ease.

Related Training

You could design a Related Training block much like the More Like This block where training events would be listed in the block just because they have been tagged with the same term. 

What if the content is a how-to piece giving a sneak preview to one of the more simpler tasks that will be taught in a series of training events? In this scenario, the author wants to control which event to advertise, but she doesn’t want to include that advertisement in her narrative.

So, in the narrative content type, you add a field that allows the author to reference the training event nodes that are directly associated with the content of the how-to lesson. Following the same concept as in the previous example, you hide the event reference field and print it via a Views block. The block appears in a predestined spot on the page.

With this approach, with some planning, the block can be configured to include a thumbnail image taken from the events in question along with date and time information, making it more than a list of the titles that appear in the reference field.

Call to Action

Your content author has created an article about a new technology that will be presented at the conference. You are not presenting a session, but you will be hosting a networking event for attendees who want to extend their conference experience and meeting others in the field. The article is not the event. There’s an event node in another section of the site.

You want a Call to Action block to appear with this article, giving site visitors a link to sign up for the networking session. The common practice would be to create an advertising block and then place that block to be visible for this specific article.

Another strategy would be to add a field set to the content type you use for your narratives such as blogs, news, and how-to lessons. You would add an image field, a text field, a link field, and an on/off field. They would not be set to show. Instead, a contextual view block would be created, one on the lookout for someone to fill in the call-to-action fields and turn it on.

The Call to Action block will show up at the author’s discretion in a place on the page decided by the User Experience designer during the planning phase of your website development project.

Archive

Drupal 8 ships with a predefined View called Archive. It provides a block that lists months and includes a number representing how many nodes were published in that month. By default, all nodes are included but that doesn’t mean you can’t add filters to limit what gets included in the count.

Not all narrative content will be enhanced by including an Archive block, therefore having it enabled by default, could take up screen space needed for other more useful blocks. So, how does a content author turn this block on and off as needed? 

First, identify the scenarios where your users would benefit from being able to find previous narratives in common with the one they are viewing.  Then, using the same strategy applied for the Call to Action block, add an on/off field for the Archive block. Edit the Archive View to look for this field to be set to on.

This scenario and the previous one will depend on your trust in the author to know when to turn on Call to Action and/or Archive. That’s where business rules come into play and ensuring all know how to follow them. 

Guest Speakers

This time, your content author is creating an event with multiple guest speakers. You have decided that creating a speaker page for every guest could amount to many nodes that aren’t worth maintaining. Instead, you want to link to the speaker’s own website.

Of course, you could make this information available is a list of links as part of the event, but given all the data you are already including, it’s been decided that highlighting the speakers in their own blocks is a better option.

Using the same strategy enabled in the Call to Action scenario, you create a set of fields: image, text, link, on/off. This time, however, you need the ability to have multiple speakers so you need this set of fields to repeat. There is a module called Paragraphs that will be your friend in this example.

Paragraphs allow you to create a set of fields that can be repeated on the page. Instead of including them in the display, you use a View to show the information in a block.

Performance

You might be starting to wonder about the performance of your site with all these queries on the database. And, you would be right to be concerned if you had no caching plan in place. Outside of Drupal, you have caching tools such as Varnish that can help deliver your pages quickly.

Have a Plan

When it comes to Drupal, using your imagination is key to empowering your content authors. Start by mapping your processes. Ask yourself what has to be available in order to execute the process differently.

Remember, you don’t have to teach your content authors how to create and place blocks. You can plan ahead and give them simple options within the environment they will already be working. Assuming default processes are your only option can frustrate your users.

Need Help?

Promet offers best practice Training to help give your team the know-how to be prepared for these scenarios. Want to run scenarios like this by our experts to get advice on pages, or even plan a new website from the ground up? Promet is happy to create small and large planning exercises for you and your team to get the most out of your Drupal site.

Oct 15 2018
Oct 15

If someone sues you because your website has accessibility issues, it usually means they need you to fix said issues. Sadly, there will be those lawsuits where the complaint is trigger more by the desire of monetary compensation from a settlement than the present accessibility issues, but in either scenario, there has to be grounds for the complaint which means something needs remediation on your site. 

Why are we stating the obvious? Because it's not obvious to all who find themselves with a letter or lawsuit claiming that their website is inaccessible and therefore discriminates against individuals with vision, hearing, and/or physical disabilities under ADA Title III.

Defenses against inaccessibility claims that have been seen in the news include:

  • Websites aren’t included under ADA Title III
  • Even if they are, it’s moot in this case

ADA Title III Defense?

On October 31, 2017, a letter was sent to The Honorable Jeff Sessions, Attorney General, United States Department of Justice, and signed by sixty-one Members of Congress, urging the DOJ “to restart the process of issuing regulatory guidance regarding the Internet under Title III of the ADA.”1

Restart? Yes. 

In this same letter, the sixty-one Members of Congress reminds the Attorney General that the DOJ, in their 2010 ANPR, states “Although [DOJ] has been clear that the ADA applies to websites of private entities that meet the definition of ‘public accommodations,’ inconsistent court decisions, differing standards for determining Web accessibility, and repeated calls for [DOJ] action indicate remaining uncertainty regarding the applicability of the ADA to websites of entities” included in Title III. 

Unfortunately, the 2010 Advance Notice of Proposed Rulemaking2 where “the Department encourages small entities to provide cost data on the potential economic impact of adopting a specific requirement for website accessibility and recommendations on less burdensome alternatives, with cost information,” has been given a status of inactive under Trump’s Unified Regulatory Agenda released in July 2017.3 

On July 19, 2018, another letter was sent to the The Honorable Jefferson B. Sessions, III by the Attorneys General of 18 states and the District of Columbia on the same topic sent by the Members of Congress.4

If the DOJ recognizes that Title III is unclear, is it no wonder that site owners still try to claim that websites aren't included in Title III? No. 

However, as you read about website accessibility cases in the news, it’s clear that the courts have decided that it does. Whether it was the Winn Dixie case in June of 20175 that set the precedence or that the plaintiff in this case has brought other similar suits since then, it doesn’t matter. Compliance with the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG), level AA is here to stay. Whether its WCAG version 2.0 or the recent 2.1, courts are ruling that these guidelines must be met.

So, what other defense can a business make to stop a website accessibility lawsuit? Other than remediating the problem?

Moot Defense?

If you aren’t a lawyer, you might be scratching your head right now. Moot? Don’t worry, you’re not the only one. Let’s start with a simple example.

Carroll v. New People's Bank, Inc.6

Filed in November, 2017 and terminated in April, 2018. First, please note the length of time required to adjudicate this case, only to have it dismissed. Here is a brief look at what transpired.

  • “NPB's website contains accessibility barriers, which Carroll alleges prevent him from using screen reading software to freely navigate the site.”
  • “NPB informed Carroll of its intent to develop a new website by letter in November 2017, prior to the filing of his lawsuit. In this letter, NPB stated that they had "voluntarily made a number of improvements" to the website and had "retained a third-party to develop a new website for the bank which [would] further improve [the website's] accessibility and client service feature-set."”
  • “Carroll argues that this new website does not render his claim moot because there is no guarantee that NPB will not revert to its former inaccessible website in the future.” 
  • “NPB has moved to dismiss the Complaint for lack of standing.”
  • “NPB contends that, in any event, Carroll's claim is now moot based on its voluntary upgrades made to the website after this action was filed, which upgrades Carroll does not dispute.”

Obviously, there’s more to this case than the snippets provided here. In fact, the case is interesting reading. Bottomline, NPB responded to Carrol’s letter, fixed the site, and the case was dismissed.

Haynes v. Hooters of America, LLC7

This next case isn’t as straightforward as Carroll’s claim being moot. This one is about getting sued twice for the same issue. Here is brief look at the ruling.

  • “On April 4, 2017, Haynes sued Hooters in the United States District Court for the Southern District of Florida …” In short, Haynes wanted Hooters to fix the accessibility issues on their site.
  • “Prior to the initiation of Haynes’ suit, on August 22, 2016, a different plaintiff filed a separate and nearly identical website-inaccessibility lawsuit against Hooters. Less than three weeks after the filing of that suit, the parties reached an agreement and settled their dispute (“Gomez Settlement Agreement”) ...”
  • “Hooters moved to dismiss Haynes’ suit, arguing that, because Hooters was in the process of actively implementing a remediation plan for its website, pursuant to the Gomez Settlement Agreement, there was no live case or controversy and Haynes’ claim must be dismissed on the mootness grounds.” They had until September 2018 to fix their site.
  • The district court agreed with Hooters and dismissed the case.
  • But, Haynes didn’t agree, and neither did the Eleventh Circuit in their June, 2018 ruling that “the case is not moot.” 

Again, there is more to this case that is briefly summarized here. In short, Haynes had no way to know or to ensure that the remedies being planned would resolve the issues he was having with the site. Therefore, his claim was valid. Yes, you can get sued twice for the same thing if the issue is still present on your site. 

Lessons Learned

There are four lessons worth mentioning. 

Audit Your Site Before You Get Sued

There is no argument that it’s going to cost you money to have your site audited appropriately for accessibility issues and ultimately remediated if problems exist. You could wait to see if you get caught but at that point, your costs include legal fees plus the audit and remediation.

Other costs include the negative publicity that can ensue. Web accessibility cases are hot topics and will remain so due to the lack of specific ADA regulations from the DOJ. People want to know how courts are ruling and that means numerous blog posts and speculation where your business’ name is spattered over the Internet.

Website Accessibility Insurance

Insure your site. You heard right. Insurance. You have a site right now. You think all is well. You have processes in place that audit content as it goes live to ensure there aren’t any issues. You have run an automated tool on sample pages and everything looks okay.

However, as a person that drives a car or owns a home knows, you can never predict when something is going to go wrong. That’s why you have insurance.

Don’t believe that such insurance exists? Think again. Beazley Insurance is working with Promet Source to offer insurance against ADA website compliance claims. Said policy includes up to $25,000 coverage for an accessibility audit and remediation if someone files a claim against you.

“In 2017, 7,663 ADA Title III lawsuits were filed in federal court — 1,062 more than in 2016.”8 “If ADA Title III federal lawsuit numbers continue to be filed at the current pace, 2018’s total will exceed 2017 by 30%, fueled largely by website accessibility lawsuit continued growth.”9 Add to these numbers the cases brought in state courts and it’s not hard to believe that you could get sued in the near future.

Move Quickly

If you get a letter, move quickly to remediate those items specifically noted. In the case of Carroll v. New People’s Bank, even if Carroll could prove standing, in the long run, NPB responded quickly and fixed the issues in the letter. 

Has Hooters moved quickly? How much money do you think Hooters could have saved in legal fees by taking down their inaccessible website and quickly replacing it with a simple, accessible website until their new site could be designed, developed, and launched? You decide.

Quick Might Not Be Fast Enough

It’s clear that people with disabilities are no longer hesitating to file suit for an inaccessible website. Whether they have standing or not, you could be faced with one lawsuit after another until you can audit your site and remediate it accordingly. And, given the findings in Haynes v. Hooters of America, LLC, the courts might let each lawsuit stand. So, circling back to the first lesson, have your site audited using automated and manual testing, get it fixed if issues are found.

Conclusion

Until the DOJ responds to the pleas of lawmakers across the nation to create specific regulations regarding website accessibility, courts will continue to review other cases to determine what’s moot or not. Don’t wait to find out. Get audited. Fix the issues.

If you don’t know what to do, Promet’s Accessibility Audit, Remediation, and Training Roadmap will help you end a current lawsuit and prevent any future lawsuits.
 

Footnotes

1. https://www.cuna.org/uploadedFiles/Advocacy/Priorities/Removing_Barriers_Blog/ADA%20DOJ%20ES-RD%20Letter%20-%20FINAL.pdf
2. https://www.ada.gov/anprm2010/equipment_anprm_2010.htm
3. https://www.reginfo.gov/public/do/eAgendaMain
4. https://www.cuna.org/uploadedFiles/Advocacy/ADAAGLetter71918.pdf
5. https://www.adatitleiii.com/tag/winn-dixie/
6. https://casetext.com/case/carroll-v-new-peoples-bank-inc
7. https://law.justia.com/cases/federal/appellate-courts/ca11/17-13170/17-13170-2018-06-19.html
8. https://www.adatitleiii.com/2018/02/ada-title-iii-lawsuits-increase-by-14-percent-in-2017-due-largely-to-website-access-lawsuits-physical-accessibility-legislative-reform-efforts-continue/
9. https://www.adatitleiii.com/2018/07/website-access-and-other-ada-title-iii-lawsuits-hit-record-numbers/
Sep 19 2018
Sep 19

You can’t build a website without a plan. A plan derived from requirements collected and a design created. You also need a development and testing plan that reflects the appropriate strategies for meeting said requirements and design. After you launch your website, you need a maintenance plan to ensure that your code remains secure, your content remains accessible, and your future features are integrated correctly.

Of all the development methodologies, past and present, there is not one that supports the development of software without requirements and design. When choosing a methodology, be it one based on the 12 principles listed in the Agile Manifesto, or not, you will not be able to avoid the effort of creating plans.

Agile Misunderstandings

Among the many misunderstandings regarding Agile methodologies is the aspect of planning. The belief that upfront planning isn’t needed and therefore time can be saved on a project is a misunderstanding of the iterative and incremental approach to software development. Think about it that for a moment. Can you create or build anything without some kind of plan? Be it simple or extensive?

It’s also a misunderstanding that said plans, if any, don’t need to be documented. If you choose an Agile methodology, you will quickly learn about Epics and the Backlog. Epics are large user stories while the backlog is a list of requirements derived from said user stories.

So, Agile isn’t about skipping the planning aspects of the project. It’s about changing the way the planning and development are conducted. And, the first step in the process of planning your site is gathering the appropriate players together.

The Right People

If you are going to put out a request for proposal, you need to include some of the requirements. Perhaps not all the details, but enough that a vendor who wishes to bid on your project can anticipate potential costs. Later, these initial requirements will fleshed out with the vendor whose bid you choose.

So, who needs to be in the room when you start brainstorming what you need? Who will ensure all requirements are identified? 

  • The money person would be good. They will know the budget and can remind you of the fact as the ideas start to mount.
  • The content manager is important. You will need to understand the tasks involved in creating and posting your content. For instance, how will you manage the publication of your content once it is uploaded to your site?
  • Let’s not forget the person who is in charge of your current site. This is the stakeholder who knows where the bodies are buried. They know why the current site is what it is and if certain aspects of the site can't change.
  • Other process owners. Depending on the tasks that your site will support, such as e-commerce or document download, who knows the most about how these tasks should be performed?
  • The naysayer. The squeaky wheel. Who is your Eeyore. “It will never work.” Get them in the room because you want the devil’s advocate. You want to hear what might not work and why.

Bottomline, anyone responsible for an aspect of the site, be it backend support or frontend interactions, get them in the room. You want to cover all your bases.

Agile Upfront Planning

“In 1998, Alistair Cockburn visited the Chrysler C3 project in Detroit and coined the phrase ‘A user story is a promise for a conversation.’”1 Then, in 2001, Ron Jeffries, one of the original signatories of the Agile Manifesto, proposed a ‘Three Cs’ formula for user story creation: card, conversation, confirmation, making user's stories part of the world of Agile methodologies. Coupled with use cases, Agile planning seeks to identify requirements and design before development begins.

However, as you will see, the level of requirements detail depends on several factors such that not every minute decision is made at the start. Let’s look at this idea more closely.

User Stories

User stories are typically brief statements written from the user’s perspective. For example, “As the content author, I need to be able to edit a page so that I can add a header image.” The documentation of such statements can be facilitated with index cards, Post-it notes, wireframe sketches on printer paper, or anything that meets your team’s needs.

A collection of such user stories helps to confirm the scope of the project and can reveal foundational requirements such as which framework or platform to use. Such stories also reveal relationships and thus where shared code will be used, for instance. 

At this point in the planning process, the team might decide to start developing. Such a decision is made possible by today's systems and platforms with plugin and play capabilities. They provide a way to support the user story tasks so that said tasks needn't be reinvented via a use case.

If user stories are unique and more detail is needed, creating use cases is the next step.

Use Cases

If system default tasks are not what is envisioned or additional tasks need to be supported, the team may choose to clarify the user stories via use cases - details of actions and events that define how a user interacts with the system. 

Deeper investigation into the requirements can help define a development path that supports both the overall system architecture required but also the specific tasks required of the system.

Once the stakeholders and development team have gained a common understanding of what is required, the user stories and use cases are converted into epics and the necessary backlog of development tasking.

So, Agile methodologies support the requirement and design phases listed in the Waterfall methodology, it just does it by engaging methods that have proven easier for end users to envision as they communicate what it is they want from the product being created. 

Of course, this isn’t the only time during the iterative and incremental development approach where planning takes place.

Agile Planning in Development

With epics and a backlog populated, the development team plans a series of iterative and/or incremental development efforts, commonly referred to a Sprints. The way the Sprints are defined depends on the overall development strategy required to build out the product, in this case, a website.

Before each Sprint, the existing requirements (based on user stories and use cases) are reviewed and specific strategies are chosen for meeting said requirements. This might include a conversation where details are clarified or added to use cases.

After each Sprint is complete, the product owner is asked to confirm that expectations have been met. If not, requirements and design aspects can be changed to correct misunderstandings or to acknowledge a new idea or need. In other words, additional planning is interjected into the development cycle and the project is adjusted.

In addition, lessons learned are collected and decisions are made regarding how-to strategies for the next Sprint. You might be thinking that enabling changes to the original plan might introduce scope creep. And, you would be right. It can.

Planning and Scope Creep

Scope creep is similar to what happens when you think you are buying the base model of a new car and you leave the lot having spent 20% more than planned because you decided on several add-on features. 

Several factors can influence the possibility of scope creep on a website. Let’s consider two related to planning.

  • Insufficient upfront planning. We aren’t talking about getting into the details of how features on your site are developed in this instance. Instead, it’s about ensuring that all user stories have been identified along with supporting decisions. For instance, if the user needs to be able to categorize an article, has the supporting requirements such as the information architecture been defined? 
  • Incorrect stakeholders at the planning table. The budget folks will have a different take on requirements than say an end user. Content manager will be able to enlighten decision makers on processes that are required to ensure a specific level of content quality. Without the appropriate people involved in the planning process, you might find that a Sprint doesn’t meet expectations.

Conclusion

An Agile approach to website development relies on planning to be successful, however, not all planning is required before development starts. Of course, there are risks associated with moving quickly into development, one being scope creep. 

The power of Agile methodologies isn’t about being able to skip steps that a waterfall methodology is criticized for enforcing. It’s about being flexible. It’s about being able to adjust as forgotten requirements are remembered. And, it’s about continuous feedback, ensuring what was originally thought to be a good idea, still works. 

Promet and Planning

Promet offers a unique planning engagement that we call our Architecture Workshop. This workshop is a customized engagement that engages all of your stakeholders in the Discovery Process.We do a 3-5 days of intensive onsite exercises with stakeholders (for your busy C-level folks we customize the agenda to bring them in where they are needed during this onsite). Then the team goes away and produces a set of deliverables that  includes a full-field level Architecture Blueprint of the website(s). Whether you choose to use a waterfall or agile development methodologies - you have everything you need to build the website everyone has agreed upon. 

Not building your site and stressed out about getting an accurate quote? Investing in this kind of Workshop will make sure that you get the right Partner, and the best price.

Footnotes

1 
https://en.wikipedia.org/wiki/User_story
Aug 30 2018
Aug 30

Perhaps you’ve heard that the W3C (World Wide Web Consortium) has updated their Web Content Accessibility Guidelines (WCAG) 2.0. 

  • On April 24th, 2018, W3C posted a proposed extension of Web Content Accessibility Guidelines (WCAG) 2.0, referred to as WCAG 2.1.
  • On June 5th, 2018, WCAG 2.1 was no longer considered a proposal. WCAG 2.1 includes 2.0 and 17 new criterion.

When will I need to update my website?

Is there a law someplace that answers this? An official interpretation? A lawsuit that references the new criterion?

To date, in the United States, there is an understanding that WCAG 2.0, levels A and AA, is the required version and levels of accessibility required to create an ADA compliant website. Court case summaries posted by the legal community say this is so.

But, as of August 2018, this reviewer can’t find a court case that references WCAG 2.1. 

Should you sigh in relief? No. Right now, the courts are interpreting Titles II and III and hearing complaints. Will a judge bring his or her hammer down on one of the new criterion if you aren’t compliant with it? Quite possible. One would hope for a reasonable ruling: no penalties and perhaps a date allowing you time to fix the issue given the newness of the additional criterion.

As soon as this happens, you have your precedence. You have your clock. Of course, until Section 508 is updated, federal site owners are protected, but that doesn’t mean said site owners should ignore the new criterion as they update or rebuild their sites.

What kind of changes will we see?

WCAG 2.1, according to https://www.w3.org/TR/WCAG21/, “was initiated with the goal to improve accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices.”

The fact that these new criterion were added with mobile devices and users in mind should not come as a surprise. In 2015, the W3C released Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile. They’ve been working accessibility for mobile devices for some time. 

Are we talking about a lot of change?

Depends on what you are doing on your site. It’s possible you have nothing to do or change in order to meet one or more of the 17 additional criterion. Perhaps you are hoping that most of the 17 criterion are level AAA and you won’t be held accountable. Let’s clear this one up right now. Twelve of the 17 are A or AA.

At this point, we could simply list the new criterion by the principles of POUR (Perceivable, Operable, Understandable, Robust) or by level, leaving you to mentally map the criterion to how you think about your site and its functionality.

Instead, the following is offered in hopes to provide a unique and helpful perspective on the new criterion.

  1. Interactions and Orientation
  2. Content Structure
  3. Visibility
  4. Cognitive

Each criterion will be briefly explained. You will benefit from reviewing the criterion’s Understanding pages as that is where you will find a more precise set of instructions.

Interactions and Orientation

Your site is “touched” and “viewed” using multiple methods.

The oldest method being via mouse or touchpad and the pointer they control on a computer monitor. Next up is the keyboard and monitor. WCAG 2.0 included criterion 2.1.1 Keyboard, for example, to address keyboard tabbing on websites. 

Given the fact that mobile devices and touchscreens are pervasive in the world today, it’s no surprise that several of the new criterion are focused on “touching” and “viewing” said technology.

  • 1.3.4 Orientation (A)
  • 1.3.5 Identify Input Purpose (AA)
  • 2.2.6 Timeouts (AAA)
  • 2.1.4 Character Key Shortcuts (A)
  • 2.5.1 Pointer Gestures (A)
  • 2.5.2 Pointer Cancellation (A)
  • 2.5.4 Motion Actuation (A)
  • 2.5.5 Target Size
  • 2.5.6 Concurrent Input Mechanisms (AAA)

Success Criterion 1.3.4 Orientation (AA)

Bottom line, don’t prevent someone from viewing your content in the display orientation of their choosing. Of course, there are exceptions, but if you don’t have to lock your content in portrait or landscape display, then don’t. This isn’t a feature you would accidently enable, especially if your site is responsive.

Success Criterion 1.3.5 Identify Input Purpose (AA)

You know when you fill out a form online that includes your name and maybe your address and all you have to do is start typing and you are given the option to autocomplete the form? Autocomplete is a feature in HTML5.2. This works because there is a defined purpose to the field.

Criterion 1.3.5 is about ensuring the purpose of the field is clear. They reference the autocomplete technology as a means of satisfying this criterion. However, the intent is “to help people recognize and understand the purpose of form input fields. … form input fields require programmatically determinable information about their purpose.”

If you have forms on your website, you might want to look into whether you are already using HTML5.2 and providing input purposes.

Success Criterion 2.2.6 Timeouts (AAA)

Not everyone can interact with your site forms quickly. It can take time to fill in a field thus creating lengthy interactions.

So, are you collecting job applications online via a form? Are your visitors entering data for anything that might take more than a minute or two? This one's for you. 

It’s likely that you are already advising your visitors that there is a time limit for interacting with your site, if indeed there is one. If not and there is a chance that their efforts will be in vain if the session times out, you need to warn them. If you are storing their data as they go along and thus there are no concerns if they walk away and return the next day, providing a timeout notice is not required.

Success Criterion 2.1.4 Character Key Shortcuts (A) 

Are you adding keyboard functions to your pages? No? Then you are good to go. If yes, then you have a new criterion to review. You don’t want to override an existing keyboard shortcut implemented by assistive technology. This criterion give you guidance in the changes you might need to make.

Success Criterion 2.5.1 Pointer Gestures (A)

What are pointer gestures? Have you ever used two fingers to zoom in or out on your mobile device screen? If you are providing an interface, such as a map, where the user would want to zoom in or out, you might need to add a single input option. According to W3C, including [+] or [-] buttons will accommodate this criterion. For other examples, visit 2.5.1’s Understanding page.

Success Criterion 2.5.2 Pointer Cancellation (A)

Have you ever clicked on a link and upon pressing down you wish you hadn’t? Perhaps you know that moving away from the link as you release your click will cancel your request. Well, in this criterion, they are focusing on actions you might have added to your page via Javascript, for example. Actions that would prevent a click or touch from being cancelled.

If you have, you need to edit your code to not include a down event such as touchstart or mousedown. W3C includes other alternatives to tweaking your code. Instead of repeating the official details here, please visit 2.5.2's Understanding page.

Success Criterion 2.5.4 Motion Actuation (A)

Do you have an app? Is your site presented via an app? If yes, this one might apply to you. This criterion is focused on interfaces that respond to device movements. Not a common feature on websites presented via a browser but definitely a possibility in apps you might be using to present your content.

If you have added functionality to your app that, for example, advances a user to the next page when they tilt their devise, then you need to pay attention to this one. Users need the option to advance to the next page via the user interface and not when their hand accidently moves, mimicking a tilt.

To prevent your application from behaving as such in a mobile device,  you need to add a setting that disables the response to movement.

Success Criterion 2.5.5 Target Size

On a full screen display, it’s easy to imagine large buttons, for example, being acceptable from a design perspective. Shrink that web page down into a small mobile device and that button can become a tiny dot that someone has to hit with a finger or other handheld pointer.

If you have buttons or links or other features that require interaction, they need to be big enough to be touchable - even on the small mobile screens. The Understanding page for 2.5.5 presents a couple scenarios that you should review if you have such interactive links on your pages.

Success Criterion 2.5.6 Concurrent Input Mechanisms (AAA)

To say this is a level AAA criterion seems odd to this reviewer. Why would you prevent someone from using an external keyboard to enter data or interact with your site versus the in-device touchscreen? If you aren’t doing this on purpose and your site doesn’t care what a user uses (mouse, keyboard, touch), then you can check off a level AAA criterion.

If you have an essential reason for such a restriction, then, okay. Although the criterion doesn’t say you have to explain yourself, the instructions for such interactions might be a place to make this clear.

Content Structure

It’s not just words that convey meaning. It’s the style and shape of the content. You might recall two criterion introduced in WCAG 2.0 that focused on ensuring that a user of a website would not miss out on what the content is saying or implying.

  • Criterion 1.3.1’s intent is “to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes.”
  • Criterion 1.3.2’s intent is “to enable a user agent to provide an alternative presentation of content while preserving the reading order needed to understand the meaning.”

Two new criterion have been added on this note. 

  • 1.4.10 Reflow
  • 1.4.13 Content on Hover or Focus

Success Criterion 1.4.10 Reflow 

If your site or app is already responsive, you are well on your way with this one. As long as your content fits in a user’s screen such that only one form of scrolling is required, then you are set.

Your goal is to accommodate a 320 CSS pixel vertical width. Or, 256 CSS pixel height. 

Criterion 1.4.10 is extending the efforts made by criterion 1.3.1 Info and Relationships and 1.3.2 Meaningful Sequence in hopes of ensuring content and functionality are not lost. This time, it’s about resizing versus removing visual and layout styles. If your responsive breakpoints are such that a user need to scroll in two directions to experience your content, then you need to update your code.

Success Criterion 1.4.13 Content on Hover or Focus

Do you provide popup content such as tooltips? You know when you hover over an image or text and you get additional information clarifying the image or text?

If you need to use this type of content delivery, WCAG 2.1 is recommending guidelines that will make such content easier to “see.” For example, when the popup tip appears, ensure that it remains until the user moves away from it. Also, don’t let the users pointer block the content in the popup. 

Of course, more details and explanation can be found on the criterion’s Understanding page.

Visibility

Not everyone can see small text. Not everyone can easily distinguish text from its colored background. WCAG 2.0 gave us three criterion to follow in an effort to accommodate such users of web content.

  • 1.4.4 Text Resize
  • 1.4.3 Contrast (Minimum)
  • 1.4.6 Contrast (Enhanced)

In WCAG 2.1, the following are added to this list.

  • 1.4.11 Non-text Contrast (AA)
  • 1.4.12 Text Spacing (AA)
  • 2.5.3 Label in Name (A)

Success Criterion 1.4.11 Non-text Contrast (AA)

You are already abiding by the contrast criterion for text and images of text if you are meeting WCAG 2.0. 1.4.11 makes some addition to contrasts.

First, you know when you hover over a button or link and it changes? That is a state change. You are going to need to ensure the change meets a 3:1 contrast ratio. Next, it’s not just about color on color but now there is a need to consider color next to color.

The Understanding page for 1.4.11 gives examples such as pie charts and icons lined up next to each other. The potential design impacts discussed on this resource page are definitely worth a read. Too many considerations to list here.

Success Criterion 1.4.12 Text Spacing (AA)

Similar to 1.4.4 Resize text, 1.4.12 wants to ensure that changes in the spacing between lines, paragraphs, letters, or words, they won’t lose content of functionality. So, you might need to check your CSS to ensure the following are possible:

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

Success Criterion 2.5.3 Label in Name (A)

This next criterion isn’t as direct as the last two when it comes to visibility of content, but reminds us of the fact that there is more than one way to “see.”

Depending on how your pages were made, you might have both visible and invisible labels on your site. Visible for those who can see the label, such a sign-up button, and invisible, a version of the label that assistive technology reads. Similar to when you create a link to a page and ensured the link and the page title were the same, visible and invisible labels need to match.

What happens when they don’t? A user speaks the label they see and their assistive technology looks for the same words. When visible and invisible labels differ, the technology can’t find what the user needs. 

Cognitive

You don’t have to have cognitive impairment to not understand something. In WCAG 2.0, three criterion are worth noting when it comes to understandable writing.

  • 3.1.3 Unusual Words (AAA)
  • 3.1.4 Abbreviations (AAA)
  • 3.1.5 Reading Level (AAA)

Just because they are AAA level criterion, that doesn’t mean they should be dismissed. They are three of the easiest AAA criterion one can strive towards.

WCAG 2.1 has added criterion that this reviewer feels fits with enabling users of your content to gain a better understanding of what it is your are conveying.

  • 1.3.6 Identify Purpose (AAA)
  • 4.1.3 Status Messages (AA)
  • 2.3.3 Animation from Interactions (AAA)

Success Criterion 1.3.6 Identify Purpose (AAA)

It’s likely that you have at least one of the following on your site: user interface components (e.g., buttons, link, fields), icons, or regions. And, if you are following the requirements of 4.1.2 Name, Role, Value, you are defining most if not all of these.

However, what you might not being doing is providing information about what the component represents, such as an image link represents a link to the homepage. This criterion wants you to convey more than a name, even if the name seems to convey the applicable meaning. Remember, assistive technology is not Artificial Intelligence. It’s needs you to tell it what it can’t surmise on its own.

Success Criterion 4.1.3 Status Messages (AA)

If you are using a content management system designed for accessibility, like Drupal 8 for example, then you should be okay. If not, you will need to update your code to declare your system messages via a role or other appropriate properties that can be understood by assistive technology.

Success Criterion 2.3.3 Animation from Interactions (AAA)

Does this criterion address an interaction or is a cognitive distraction? Perhaps both.

Do you have things that move on your pages? Do objects fly in from the side as someone scrolls? Criterion 2.2.2 Pause, Stop, Hide from WCAG 2.0 applies when the page initiates an animated object. You might have heard of this one. 2.3.3 is intended to prevent animation from being displayed on the pages in the first place.

If you have a dynamic page with moving parts, you need to look into this one. You might need to add to existing animation controls and allow users to keep them from appearing. Of course, this is level AAA, but it’s worth considering as sudden movements can trigger vestibular (inner ear) disorders and cause dizziness, nausea, and headaches.

Conclusions

If you manage a federal site subject to Section 508, that doesn’t mean you shouldn’t take the additional 17 criterion into consideration when updating or building your site. As for everyone else, WCAG 2.1 is the recommended set of criterion. With the chance that someone might claim your site is non-compliant based on 2.1, you need to look into bringing your site up to date.

Remember, some of the new criteria are, by default, not going to be in play on your site. Many of them have to do with added bits of code that override default browser behavior that at one time were deemed acceptable. So, WCAG 2.1 doesn’t have to be scary.

Aug 30 2018
Aug 30

Since its launch, many have written about all the great technology that has been added to Drupal 8. You will find articles online talking about such added features as headless and responsive and accessible. You will read about modules that have been added to core, contributed modules once part of the standard recipe for configuring a Drupal site.

And, that's all good news if you are developer assessing building blocks and code. But, what if you are a business owner, marketing executive, or technical decision maker and don't speak Drupal yet? 

You have a laundry list of features and functionality you want supported by your site and you just need to know if, and a little bit of the how, Drupal 8 is going to meet your needs. Although a planning workshop and Drupal builder course could help you gain a strong understanding of Drupal, you aren’t there yet.

Recognizing this might be you, this article:

  • Shares some of the most common and not so common requirements that you might be facing, and
  • Talks about how Drupal can help support your processes and goals.

Common and Uncommon Features Don’t Scare Drupal

Drupal is a content management system, content being the operative word. However, Drupal doesn’t see content as a blog post or an event. It sees content as data. Data comes in all sorts of shapes and sizes. It carries multiple types of meanings, from the spoken word to value that triggers an action.

When it comes to identifying that which Drupal can’t do, this reviewer only has to stretch her imagination and a solution presents itself, often using existing functionality either from Drupal’s core and from millions that call themselves part of the Drupal community.

In order to demonstrate Drupal’s potential without the aid of video, the remainder of this article will address several capabilities - simple and a little more complex - in hopes that it will help you recognize that Drupal can meet your needs.

When working with managers such as yourself, request often start out as, “I want …” and finish with one or more of the following:

A Mobile Friendly Site 

You are likely one of the majority who surf the net using a mobile device like a smartphone and thus you know what it's like to visit sites that don't fit your screen. Perhaps you have decided that you don’t want to be that business that can't be easily experienced from any device.

Screen shot of default Drupal 8 homepage in it's most narrow display.

Drupal 8 makes it easier than ever to make responsive sites. Responsive means your web pages flex and reshapes automatically to fit your screen. Although responsive functionality was available in previous versions of Drupal, Dries Buytaert, the inventor of Drupal, decided that Drupal 8 would bring mobile to the top of his improvement list.

One of the first steps taken to make this possible was making the jump to HTML5 in order to gain such advantages as engaging the applicable input device when a site is viewed on a tablet or smartphone. 

Check out the screenshot showing Drupal 8 default homepage reduced down to fit on a smartphone.

Different Types of Content

This request often goes without saying and when it comes to Drupal, its response is, “Bring it on!” Any type of content you want, it’s yours. Plus, there is more than one way to get it done depending of the type of data you want to use to define said content.

Let’s consider an example. Story telling. This could mean that you have bloggers, new reporters, media reviewers, etc. At the core of this type of content, they are the same. It’s just the words and tone and organization that often makes these different. 

If you want a separate form to collect each type of content, then you can do that. Even if all the data fields you define are the same in each, Drupal doesn’t care. You can also collect this type of content using just one form with an additional field that lets you categorize the type of content.

This is a very simple example, but hopefully it’s already making you think about how your content can be viewed as data collected in fields versus what you might be used to doing with MS Word or other content management systems.

Since Drupal 7, this type of functionality was part of Drupal’s core. In Drupal 8, the coding structure has changed, enabling your developers to tap into the objects that make this possible and invent unique content collection tools that integrate with Drupal’s permissions and other default features.

Accessible Content Formatting

There are two methods associated with formatting worth mentioning: field-based and manual application. When content formatting comes to mind, you likely think of making text bold or creating bulleted lists. That’s cool. Drupal 8 has that covered by default.

Drupal 8’s text formatting is better than ever. Style your content in MS Word and copy/paste it into your Drupal 8 content form. Don’t do this with previous versions of Drupal, you could end up with a mess of code. Also, Drupal continues to offer settings that control which content author can, for example, add images to their blogs, or not. 

When it comes to using fields other than the traditional long text fields, you can apply styling via templates and CSS. Or, you can rely of the fact that Drupal 8 is WCAG 2.0 ready (likely to be 2.1 ready in the future) and much of the formatting you need is already in place.

Collecting Data Other Than Content

Drupal 7 not only added the ability to add fields for content collection forms, but it also added the ability to add fields to user accounts so that additional data can be collected and possibly displayed for your content authors. Drupal 8 continues this functionality but with the same object oriented strategies implemented for content.

Categorize Content

Categorizing content is at the heart of Drupal. Each Drupal site ships with one Taxonomy that can host multiple vocabularies (containers that hold terms). You can have as many terms (words or short phrases that describe or categorize content) as you need.

Drupal 7 included the ability to add fields to terms so, for example, you can associate an image of an orange with the term: orange. Drupal 8’s contribution, besides better backend code, it a new display page. When someone clicks on a term, they land on a page that displays all content tagged with that term. Drupal 8 makes it possible for you to easily modify that display right out of the box. 

Block Content 

Blocks are bits on content or functionality that can be added to a page. They typically appear alongside the main body of content, or below it, above it. Historically, you would create a block, for example that says, “Welcome to my site. Become a member …”. That block could be placed in one location, let’s say the right sidebar. By default, there wasn’t much more your could do without additional modules.

Drupal 8 has changed the block system. When this reviewer learned by how much, she couldn’t stop smiling. Okay, she might have shouted with glee. 

Anyway, not only can one block be placed in multiple regions at the same time, - in a sidebar and in a footer and in the region that displays the main content - it can display something other than the text. You can now display an image via a field. Or, a video. Or, an attached PDF file.

Yes. You heard right. You can add fields to blocks, made possible by the same object oriented strategies put in place for content, users, and terms. You can also have different types of blocks, just like you can have different types of content forms.

But that’s not all! If you have a block intensive website and you ever want to get a list of said blocks and the content they content in one report, you can query the database and get that list by using the feature called Views. The Views module used to be a contributed module, a staple in 99.9% of all Drupal sites - in this reviewer’s opinion.

Multilingual Site

With each major release of Drupal, the ability to develop a multilingual site got easier. Drupal 8 has not disappointed. Where Drupal 7 required up to eight or so contributed modules to create a multilingual site that was 99% correct, Drupal 8 has four in its core to make it happen.

Coding practices that used to prevent text from being translated are a thing of the past if a module contributor wants their module to be accepted by the community.

It was possible in the past and even easier now.

Manage Content Development

It’s one thing to be able to structure your data you see fit, it’s another to manage the development of said content or data. Aside from the creative nature of content development, you have the ever present need for copy editing. And, if you believe that your content authors can easily catch their own typos, think again.

It’s fortune that the Drupal community recognized the need to manage the process from “I have an idea” to a published work. Drupal 8 has jumped on the workflow wagon by including a workflow option you can turn on and configure. 

Whether your authors compose in MS Word or in Drupal’s content form, the first, second, or even the third draft shouldn’t be seen by the public. You can tell Drupal to save as unpublished. You can collect copies of every draft version by default and switch between them until you are ready for editing.

With additional functionality from the community, you will be able to do things like send notices with draft content is ready for review. You wouldn’t be the first to have this requirement and users of Drupal have been making this happen for years.

Reuse Content in Multiple Displays

This is not the first mention of content reuse. Drupal is all about content reuse. Break your content into structured data and you can find and filter until your heart's content. And, you can then share your queries with the whomever you wish.

Views has been around since Drupal 4, but has always been a contributed module. There are good reasons for waiting to integrate Views into Drupal’s core and now that it is here, Drupal out of the box is that much better.

Most notable is the administrative pages. Hard-coded in the past, the pages that list content and blocks and users and more are now made with Views. They are database queries made into page displays and thus allow you to easily customize your admin pages.

ADA Accessible Site

Accessibility has been mentioned already, but if you didn’t notice, it’s worth mentioning again. Taking a mobile first perspective when designing Drupal 8 was only one priority. Accessible web pages was right up there as well.

The developers of Drupal 8 have taken accessibility seriously. They have reviewed WCAG 2.0 and W3C’s WAI-ARIA. The Drupal community wants your site to be easily read by assistive technology and ARIA was a big step in the right direction.

Deep down, you know how important it must be to make web pages that everyone can experience. What you might not have heard about is the fact that the number of lawsuits for non-compliance has increased and continues to do so.

It’s not just about federal government sites anymore. It’s all sites. Drupal 8 provides a strong foundation to creating an accessible site from the start.

One System, Multiple Frontend Interfaces

You don't want two systems: one that will present your information in a web browser and one that will present your content in a mobile app. Data reuse is a key feature in Drupal and Drupal 8 takes the next step.

Drupal is now what some call “headless” and others call “decoupled”. It doesn't matter which word you use as this functionality is a technical thing that your developers can take advantage of when they present your data through multiple interface frameworks. 

What does this mean? It means you can serve up your content to an app who’s interface was created with a framework designed for mobile devices while at the same time, present content in a browser the traditional way. One blog post, two tools to manage said display. 

This simple example does not suggest that you can only have two frontend interfaces to your content. If you are looking for a central repository for your digital content and you want to deliver it to multiple platforms, Drupal 8 makes it easier than ever before.

Wow, talk about content management. Create it and edit it once and use it over and over.

Affordable Upkeep

This might be the last topic, but that doesn’t mean it’s an afterthought. Like many software applications, significant changes occur from one major release to the next. Unlike many software applications, you don’t have to start over to use the next version.

For a time, you could actually upgrade your Drupal site to the next major release. This reviewer went from Drupal 4.5 to 4.7 to 5.0 to 6.0 before migrating to Drupal 7. Drupal’s backend restructuring to keep up with today’s technology introduced some challenges when it came to taking a Drupal site from version 6 to version 7 and the developers listened to the complaints.

So, Drupal 8 has a few features worth noting as they can impact the cost of managing and maintaining your site.

  • Drupal 8 ships with a Migrate modules to help you tap into Drupal 8’s new functionality by making it easier to migrate.
  • Drupal 8 ships with a Configuration Synchronization module that allows you to launch a version of your site and easily add new features as resources allow.
  • Drupal 8’s path to Drupal 9 isn’t going to come in one giant leap like past major releases. Drupal 8’s development is taking semantic path with releases such as 8.1, 8.2, 8.3, and so on until 9.0 is reached.

These three strategies alone make Drupal more cost effective than ever before. Your development team will have a learning curve to come up to speed on the semantic coding process, but otherwise, they will find Drupal 8 to much more conducive to long term commitments. 

Conclusion

If you want a system that can build just about anything, like one can do with LegosTM , then Drupal 8 is where you want to be. If you have a simple blog site or a content rich site viewed by the world, Drupal can handle it.

The advantages discussed above just scratch the surface of what is possible. Other requirements that Drupal can handle include:

  • Advanced permission settings
  • Powerful content development and layout options
  • Integration with other systems
  • Mash ups - pulling content from other sources
  • eCommerce
  • And more

So, if your requirements are anything like what was discussed above, or if you have something truly unique, let us know. We love a challenge.

Jul 31 2018
Jul 31

When it’s time for a new site, the word “migration” is often dropped in conversations. Every organization looking at a migration in the future will have their own reasons for doing so, their own history, their own future goals. In this article, we will present the following topics as a means to empower you to recognize aspects of website migration you might otherwise overlook.

  • What can a new site look like after a migration.
  • Triggers for a migration project.
  • Paths that might be taken.
  • Creating the right team.

The first two topics are going to feel like the chicken and the egg. Which one comes first? Given the linear nature of articles, they will be presented in said order, but that does not mean the order will match the scenario faced by many.

What can a new site look like after a migration?

Amazingly, not everyone has the same vision of what a new site might mean. Managing expectations from the start is critical to a successful migration project. Below are some common scenarios that can constitute a “new site” and/or “migration” that you might face in your project.

You will find that the following three categories can account for most changes.

  • Server environment change
  • Web platform change
  • Design and/or functionality change

After this, the triggers that might cause one or more of these changes is presented.

Server Environment Change

The process of taking an existing site and moving it from one web server to another would be considered a server environment change. It could entail moving your site from your own web servers to an external vendor.

From a new site perspective, this scenario doesn’t seem to fit. Technically, it doesn’t. Same code, same site. However, to your users, it might feel new if the site’s performance has improved. Your site could actually look different, assuming pages weren’t loading fully due to slow performance.

From a migration perspective, this is text book. You physically move - migrate - to a new server. In the process, you will receive upgraded or new web server features that will need to be configured to work with your site. A few examples include:

  • Caching services
  • Security configurations
  • Development, testing, and production processes.

Your website’s code might be the same, but the environment in which it lives has changed and therefore it cannot be assumed that there won’t be some work to make everything fit and function as required.

Web Platform Change

First, let’s assume that web platform refers to some type of content management system (CMS). The process of migrating from one CMS to another can yield a site that looks the same, but is it?

From the new site perspective, at a minimum, the code-base is different. The configuration strategy is different. The opportunities to improve or enhance your current circumstances can be different. Given the expense, your new system should be ready to allow for your growth in order to justify the expense.

From a migration perspective, to move your site structure, content, interactions, etc. from one CMS to another is a migration, by definition. Depending how similar the systems and how complicated the existing website, the effort to make the move can be extensive.

Example migration and level of effort scenarios might include:

  • Blog Site - Migrating a blog site from one CMS to another is likely the least complex scenario. Most CMSs are designed around enabling users to post their stories, articles, and blogs with ease so the leap should not be overwhelming.
  • e-Commerce/Product Site - The level of effort for this type of move will likely be more labor intensive than a blog site. You might be thinking, “A product is a product,” but the way the sale is managed can vary from system to system. Check out processes may differ. The way the product is loaded into the system may be simple in one, but the other CMS might offer more sales options that you need to consider.
  • Multi-function Site - Sites that provide some combination of blogs, products, events, community, manuals, custom integrations, and more will present even more challenges when moving from one system to another.

The pattern should be clear. The more complex the site that is being migrated, the greater the level of effort. This can include new planning effort, where you dig into the metadata level of content and features. Some CMSs are designed for data micromanagement and you will want to take advantage of the data reuse functionality such a system provides.

Design and/or Function Change

This is one place you will want to manage expectations up front. The scope of work implied by the word design can send your migration project into overruns very quickly. And, the idea of functionality (from a site visitor perspective or a content author’s perspective), can be interpreted many ways.

So, from a new site perspective, design and function will create the most obvious new-site feel. Whether it’s the layout of your pages, your branding, the way your information is organized and accessed, or the new online tools you add, a significant change will occur.

From a migration perspective, the move is to go from one site to another. This scenario is often combined with the first two: server change and platform change. Even if it is not, the effort for such a move is not unlike the process of planning, designing, and building a site from scratch. Even if ideas and content and branding are transferred unchanged, a version of the original website’s implementation process will need to be executed.

Triggers for a migration project.

Based on the discussion above, it might seem obvious what the triggers for change might be. That is true, to some extent. However, there are triggers that can cause a server change while others can cause a system change. Or, both.

Performing a trigger review is a good way to explore the potential, “What about …,” comments that can bubble up during development and trigger yet more change and scope creep. In this section, five triggers for change are presented, along with the type of migration that might be required:

  • Analytics
  • Search engine optimization
  • Technology
  • Mobile first
  • Organizational goals

Analytics Triggers

Web analytics are the statistical data collected about website usage. If the site is not being used, can an organization justify the expense of maintaining said site? Not likely, unless the implied triggers for change from said analytics are implemented.

Triggers of this nature can include:

  • Bounce rate - Site visitors are not spending enough time on site pages. They aren’t reading or watching or interacting as desired.
  • Low or no visits - Pages on the site are not being visited at an acceptable rate. They are either not being found, or their topics don’t meet the visitor’s needs.
  • Low or no mobile device visits - Of the visits, users are arriving on the site via a laptop or desktop. This could be justified given the site purpose, or it could be connected to the bounce rate concern, where people leave the page because it is not easily visible in a mobile device.

To remedy these situations, an analysis needs to be completed. Depending on the findings, the following migrations might apply.

  • Server change - If statistics are off due to poor performance - pages not loading in a timely manner, for example - a new server environment might do the trick. Cached pages are easier and faster to send.
  • Platform change - If statistics are off due to inaccessible pages, pages read by accessibility technology, new code is likely needed. Be it the code for the page structure or the code used to present the content, non-accessible pages can be costly in the long run due to lawsuits, for example.
  • Design and/or function change - If statistics are off due to an unfriendly Information Architecture that make site navigation cumbersome, or due to page layouts that don’t fit in the small screens of today’s mobile devices, a new design will be on your list of changes.

Search Engine Optimization Triggers

When a website lands on the first page of Google’s search results, you can claim success. You have made it. Your site will have visitors. You product will sell. You can now lean back and relax. Not really. Vigilant monitoring is needed as search algorithms are constantly changing.

What happens if when you aren’t on the first page or if you slip from your pedestal? Something will need to change. What kind of changes? If only there was an easy answer to this question, you would be rich.

There are some efforts you might need to undertake, however. For example:

  • Platform change - Using a system that can deliver a semantic web solution is one step towards making a website more understandable. If a search engine can interpret the content of the website (e.g, “price” actually means product price), it’s more likely to index the content of its pages such that they can be delivered to users in search results. How do you think Google creates the images display or the shopping display? With page content it can understand.
  • Design and/or function change - In a 2018 blog post, Google stated, “Our advice for publishers continues to be to focus on delivering the best possible user experience on your websites and not to focus too much on what they think are Google’s current ranking algorithms or signals.”

The changes you need to make will come from an analysis which will include analytics and possibly user feedback. At the end, you should know what is wrong with your current site and how you might make it better.

Technology Triggers

Technology issues can trigger a website migration. With the current rate of change in web-related technology, an older website might already be facing issues that are triggering questions like, “Will our site crash in the near future and leave our customers hanging?”

There are several technology triggers that might send you into migration mode. Here are three examples:

  • Non-secure code - Hackers are always looking to see if they can break into your site. Be it a server hack or a site hack, it can happen. And, if you think only open source products are vulnerable, think about the number of security updates you accept from Microsoft on a regular basis.
  • Too much success - Your CMS was meant for blog posts, not community forums or product sales. You are growing. Your system needs to grow with you.
  • Accessibility problems - Yes. This has been mentioned before but given the increased number of accessibility related lawsuits against website owners, it’s worth repeating. Accessibility is just about page hits, it’s the law.
  • Lack of mobility - “Mobile first” is the phrase of the day and rightly so. Most web users today are using mobile devices to surf the net. Are they surfing you?

The type of changes that might be triggered from the list above can span all three: server change, platform change, and/or design and functionality change.

Mobile First

This drum has already been thumped, but it’s worth mentioning again. We have seen it. “Hey, I was on my phone the other day and saw this cool site. It fit great on my little screen. Can we do that for our site?”

The answer is yes. Given the trend for users to use a mobile device before they reach for their desktop computer, you need join the party. Several technology changes will need to be made to your site.

  • Layout plans - Where do the sidebars go when the page is in a narrow display?
  • Responsive breakpoints - When does the layout of your page change?
  • Menus - That horizontal menu bar will need to change shape in order to be viewable.
  • Media adjustments - Are you still offering up media that doesn’t run on a mobile device? Videos, Flash animations, not all formats work. And, don’t forget images. Those 4MG images aren’t going to fly to a mobile device with ease.

What does this mean for migration? Assuming you have the server environment that can manage the increase in your page hits from going mobile, you might need the following:

  • Platform change - If you aren’t working in a CMS that allows for mobile first design, you will need to change your CMS.
  • Design and/or functionality - As hinted above, page layouts,menus, media will need to be redesigned to accommodate the smaller environments.

Organizational Goals Triggers

The last trigger worth mentioning is the need to meet organizational goals. There is some overlap here with goals pertaining to Analytics and SEO. Other goals might include:

  • Additional services - An organization that talks about books might want to add the option to purchase said books versus providing links to external e-commerce service.
  • Additional resources - Instead of just selling products, the organization wants to provide an education focused community and tutorials.
  • Membership services - Some content might be worth selling right from the browser. The addition of a membership to the website and its valued resources might be the next step to reaching organizational goals.

In each of the examples above, all three types of changes might be required. A new system to provide the new functionality hosted on a server environment that can better handle said changes. Plus, when such changes are required, it’s likely that other design aspects will need to change, hitting all three types of migration.

Paths that might be taken

Once the migration requirement is identified, there are basically two paths to be taken:

  • Do it all now
  • Do it in phases

Do it all now

There are two scenarios that easily lend themselves to this approach.

  • Migration projects such as server changes are at the top of this list. Copy the site to the new environment, test it, fix it if necessary, and go live.
  • If the site will undergo minimal changes, getting it all done now is the likely path.

Of course, any scenario discussed above can follow this path to completion. With the right plans, anything is possible.

Do it in phases

There are several scenarios where this approach might be the best approach. Here are three examples.

  • Technology threats - The current site has been hacked and off line. Instead of spending time trying to fix a potentially outdated website, select the most important features of the site and spin up a new site as quickly as possible. Then, bring the remainder of the features online as they are completed.

  • Legal issues - Lawsuits against non-accessible websites can encourage the need to move quickly. While a new site is being created on a platform that supports accessible websites, two things can occur:

  • Budget - The business is growing, but the budget is still tight. Start with the new look and feel on the new platform and server. Get the basics up and running. Then, bring the new features online as resources permit. Two goals to meet in this scenario”

Creating the Right Team

Last, but certainly not least, is the team of managers, user experience experts, designers, developers, and possibly trainers. Who will you need? Without a plan, without an exercise of “What about …?” and “What if …?” scenarios, you aren’t going to know who you will need.
 

Architecture Workshops

From Stakeholder Mapping to the Delivery of Field-Level Blueprints the Architecture Workshop is designed to take your goals and objectives for your website and provide you solid plan. Whether you develop your website in-house or use an outside firm, this workshop will help you get your stakeholders on the same page, and give your website/project manager a blueprint to ensure you get the most out of your developers.

Private Drupal 8 Immersion Training for your team

  • Get your developers trained on the latest technology by the best Drupal trainers
  • Learn what new innovations you can implement with Drupal 8

 

 

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