Deployed today:
16 Departments left to go!
Wait, what? Isn’t that what it was last time? Yes! But only because one of the departments that was waiting to see what our new site was going to look like decided that they liked the new look. So we migrated one department, but we added another one to do. So I’m still calling this one a win.
One more site deployed today:
This site is an excellent example of how we’ve been consolidating sites – if you can believe it, when we started there were 75 pages there. Now we’re down to about 7.
Just another 16 departments to go!
During our last deployment, we stumbled across a couple of errors our content editors made. When we talked to them about it, we learned that often, the editors weren’t even aware there was an issue. So I’d like to bring special attention to one of those errors that is easy to prevent, and helps make the website work better for everyone.
There’s just a little bit of technical background you should be aware of. In Drupal, every page has a node number – an internal number that Drupal uses to identify your page, independent of the page title or URL. For example, our contact page, at http://www.lanecc.edu/contact, is node 105, which you can see for yourself just by clicking those links.
The URL for your page is based on two things: the ‘chunk’ your page is assigned to, and the title you’ve given your page. For example, the page http://www.lanecc.edu/math/division-projects is in the “Math” chunk, with the page title “Division Projects”. When that page title changes – say to just “projects”, then the URL of that page will also change. The new url will be www.lanecc.edu/math/projects.
Why does this matter? Well, a number of our content editors are adding links to their pages by simply pasting a link on their page. Drupal, being a friendly, helpful CMS, automatically turns URLs into links. All is well and good until a page title changes and the URL changes. Suddenly, the pasted link isn’t to the right URL any more.
The fix is to use the LinkIt module. You might recognize it as the “Insert Link” button, from this image on our help documentation, and from the WYSIWYG editor:
When you click that “Insert Link” button, you’re given a little popup window, where you can search for content and select the page you want to link to:
There’s two input boxes in that white box. If you’re linking to an internal page, start typing in the top box, and Drupal will search page titles for you, and let you select the page you’re looking for. If you’re linking to an external (not on Drupal) page, paste the URL in the bottom box, and then just say insert – there’s nothing to search for.
Again, why does this matter? Because Drupal knows the node numbers of pages, and instead of linking to lanecc.edu/contact, it will link to lanecc.edu/node/105. When someone visits the contact page, Drupal looks up what the URL is for node 105, and gives the visitor a link to the right place. In other words, you don’t need to worry about updating internal links – we’ll take care of it for you.
Unfortunately, because not using LinkIt has resulted in a number of preventable 404 errors, we’re going to make some changes to the Drupal interface to make sure they don’t continue to cause problems. Soon, Drupal will no longer automatically link up URLs that you paste into the page – you’ll need to use LinkIt if you want them to work. And pasting a www.lanecc.edu link into the bottom box of LinkIt won’t work either – we’ve disabled that as well. *
To help get the entire site back to where it should be, we’ll be checking the database over the next few weeks and helping editors that seem to be struggling. Don’t worry – we’re just trying to make sure that all the links on the site always work. And if you are having trouble, check our help pages (Drupal authentication required), and don’t hesitate to contact someone on the web team.
* There’s also some room for User Interface improvement here, and we’re working on it, but it involves some tricky changes to some code that we didn’t write, and unfortunately user interface improvements often can’t be at the top of our priority list. But we won’t forget about this one.
As an educational institution (and as responsible web developers!), we’re very concerned with the accessibility of our website. Although our primary concern is following the Section 508 guidelines, there’s a number of other best practices we’re trying to follow.
Before I get going, I’d like to note that this post only applies to our Drupal redesign, and to the pages on www2.lanecc.edu (though we’ll soon be moving www2 to www).
508 contains sixteen standards that directly address web content. I think it’s worth looking at each of these standards in detail.
Through a combination of limiting editing functionality and filtering tags when pages are saved, we’re only allowing four non-text elements on pages: images, YouTube videos, Flickr slideshows, and Google Maps. This is a significant improvement over our old site, where we had no method to limit tags, allowing any number of non-text elements to be introduced.
When a user editing a page in Drupal inserts an image, they are prompted to add an Alt Tag, with a note about its importance in improving usability. Just to make sure no images escape our attention, we run a weekly report that checks all of the images on the site for alt tags, and alerts us if improvements are needed. Additionally, the importance of Alt tags and accessibility in general, is discussed with Drupal users during our normal Drupal training.
Unfortunately, there are some accessibility concerns with Flickr. For this reason, Flickr is not intended to be our final image slideshow solution, and is only a temporary measure while we explore alternate solutions. We’ll be rolling out an alternate slideshow solution, with a goal to be totally away from Flickr by the time we upgrade to Drupal 8. In the mean time, users are responsible for providing relevant accessibility information for their own Flickr accounts.
For more information on the accessibility of YouTube videos, see guideline b, below. More information on Google Maps accessibility can be found at http://www.google.com/accessibility/products/.
Unfortunately, there is no automated method for us to ensure compliance with this standard. To improve the likelihood of compliance, we have removed the ability to embed videos on pages from sites other than YouTube, which has the best closed captioning support, sometimes providing them automatically. During our media training, we make a special note of pointing Drupal users toward captioning resources (which can be found at http://support.google.com/youtube/bin/answer.py?hl=en&answer=100079).
As part of standardizing the appearance of our website, we’ve tried to reduce the role of color in providing information. Generally, users are unable to modify the colors of their pages, and where color is used to convey information, such as tables and alert notices, markup is provided to convey its purpose (through thead tags and alert classes, respectively).
When developing the new Drupal site, one of our goals was to make each page’s content work independently of style, not only for accessibility, but also to facilitate easily modifying page style in the future. We’ve tried our best to ensure that pages use ordered, semantic HTML, to provide hierarchy that’s easy for screen readers to navigate, and we’ve added helpful links to allow screen readers to jump over or directly to the page navigation.
We do not use image maps on our site.
We do not use image maps on our site.
When using the table wizard in our Drupal page editor (TinyMCE), table headers are automatically provided. Row headers are not always relevant, and as such are not automatically inserted. If we notice a pattern of missing row headers, we’ll add a test to our weekly accessibility and 404 check script and assist the owners of problem pages.
At this time we are unaware of any tables on the site with more than one row of header information. Multiple header rows should automatically be incorporated into a single thead tag, however at this time we depend on our users to be aware of table header accessibility issues. Again, if we notice our users are misusing table or row headers, we’ll add a check to our script.
We do not use framesets on our site, and where iframes are used (rare), they are automatically tagged with titles.
Our pages should flicker at the rate set by end users (refresh rate). For most users on LCD screens, this should be around 60Hz, though it’s important to note this isn’t something we can control.
As we are unaware of any areas of our site where we’re out of compliance, we’re planning to discontinue our existing text-only site, which was unfortunately often out of data with our main site.
Due to security concerns, the use of JavaScript is actually disabled for Drupal content editors. Javascript is only used as an integral part of two pages: The SAP Calculator and the Tuition Estimator. The Tuition Estimator is provided to us, and thus we’re dependent on the makers of that software to ensure accessibility. Neither page uses JavaScript to render interface elements. Although the SAP Calculator does depend on JavaScript to perform calculations, instructions for calculating SAP independent of the calculator are provided, as is contact information for help if needed.
Java is not required to use our website, so applets do not apply. Flash elements should prompt the user automatically if needed.
Form elements are automatically assigned names, and labels are automatically created to associate those labels with the appropriate elements. This is a significant improvement, as our old site relied on hand created forms that may or may not have had accessible elements.
The first two links on every page are hidden to most users, but should be read by screen readers. The first will allow a user to skip directly to the main page content. The second will allow a user to skip directly to the main navigation.
There are no timed responses required on our site.
As part of migrating content to the Drupal site, our content migrators were instructed to insert header tags where possible, providing a structured outline to many pages. This was a dramatic improvement, as many of our old pages simply used bold or large text to denote a new section.
Additionally, we’re developing our pages in HTML5. Although not fully supported by all screen readers, our pages are now marked up with meaningful divisions, such as nav and article, which help screenreaders to automatically find important sections of the page.
As part of moving to a CMS, all of our content editors were retrained in a series of one to four trainings. Accessibility information was distributed at each of these trainings, and linked help documentation throughout the site includes accessibility guidelines.
One common request we’ve had is to increase the default size of the text, in order to make it easier to read. This is actually an unwinnable battle, as the size of the text is actually dependent on a lot of things other than the styles we set. For example, the resolution of your screen has a tremendous impact (I know I have difficulty reading text on my 1920×1080 laptop screen that I didn’t have on my old 1440×900 laptop).
But it is reasonable for us to increase the text size some, as on the whole devices have been increasing in resolution. We will be exploring different options with CSS Media Queries to use a larger size than you may be used to seeing, even after we launch the new site. The most important change we’ll be making is to ensure pages look good regardless of the zoom level you use at home. If you increase the size of the text in your local browser, it should continue to flow correctly on our page, rather than overlap with other elements.
Although I’m not able to show them here yet (coming in a future post!), we’ve run mock-ups of our new website through color blindness simulators to make sure there’s enough contrast in our content to make it visible to all sighted users. You can get an idea of what we’re talking about online.
For a long time in HTML, tables were used not only to display tabular data but also to lay out pages, which violates the idea of semantic HTML. Unfortunately, our site was very guilty of this practice. We’ve since removed all the tables that were used for layout, and instead replaced them with appropriate block level elements.
Tables are tricky on mobile devices, as they force a width that will accommodate their contents. We tried a few different solutions, and settled on one that provides an alternate visual layout while preserving the existing table structure, which should allow screen readers to work even from mobile devices.
Because tables can be so difficult, we’ve also sought places where tables were improperly used to list data, and have converted most of those to ordered or unordered lists.
Although we are not aware of any accessibility concerns for our users at this time, we also make an effort to improve accessibility for our content editors. Drupal has some accessibility resources, as well as a group dedicated to accessibility concerns that can be helpful. The WYSIWYG editor that our users use to make changes to pages has a similar page for accessibility information. We’ve also made a conscious decision to avoid administrative modules that rely heavily on the use of javascript to provide functionality.
Possibly the most important thing we’ve done is to refocus ourselves around constantly improving accessibility. We regularly share articles about site accessibility with each other, and try to stay current on things like WAI-ARIA. We’ve also started including disability demographic information in our surveys, to get a better picture of our audience. Accessibility factors into every decision we make as a webteam.
As with any other current technology, accessibility on the web is a moving target, changing every year. We do our best to make our site accessible, and try to continually improve troublesome areas. Of course, if you notice something on our site that isn’t accessible, please let me know!
Had our first deployment of the new year today:
Otherwise, we’ve been busy developing and testing our information architecture for our new Current Student and New Student landing pages.
4 chunks deployed today:
Happy Holidays everyone!
Over the last year, we’ve occasionally been posting about page deployments from the old Lane site to the new Lane Drupal site. Today, we dramatically improved our testing infrastructure, and took a step towards a better, more accessible website.
Before we can explain that step, you need at least a grossly simplified idea of what it looks like for us to move pages. Essentially all we’re doing is manually copy and pasting over content from the old site to pages on the new site, then properly formatting and linking everything. Easy with one or two pages, but when doing a chunk of a hundred pages, it’s a tedious and time consuming process. And, as with any tedious process, it’s prone to errors.
So how to we ensure that everything worked right after a deployment? Our principle tool is a Link Checker, which is a type of Web Spider. A spider, once given a page to start on, follows all the links on that page, and then all the links on those pages, and so on. Eventually, it establishes a kind of web of a website.
When we first tried to find a spider, we found several that almost worked. The one we got furthest with was, appropriately enough, called LinkChecker. But it wasn’t quite right for our needs, and we had a lot of difficulty trying to extend it. So we did what any self respecting, overly confident programmer would do, and wrote our own.
Our first pass worked pretty well – checking some 13,000 pages and all their hundreds of thousands of links in about half an hour. But like any tool, before long, you want more power!
We experimented with adding some rudimentary spell checking, but found that doing a complete check of our site could take as long as 4 hours! And there were so many other things to add.
Over the last couple days, we’ve done a complete rewrite and realized significant speed gains. Instead of 30 minutes to check the site, it now takes 7. And adding in spell checking only makes it take 12. We also added a few other features:
The broader, more important thing we did was to make sure the framework for our link checker is easier to extend – simplifying new tests in the future. And, because its so much faster, it’s “cheap” to run a test, meaning we can do them more often to catch problem areas sooner.
Now, on to the broader problem of actually fixing all the new problems on the site we’ve uncovered….
Today’s deployment, by itself, represented 7% of all the pages we need to move. And it’s just one site!