Understanding WCAG 2.0: 1.4.4 – Resize Text

The next standard we’ll explore in our series on understanding WCAG 2.0 is 1.4.4, Resize Text. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text:

1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)

This one might seem super straight forward, but there’s a bit of subtlety to it.

It used to be that browsers didn’t zoom, they’d actually just increase the font size. If you pressed Control + you’d increase the font size (Command + on a Mac), and if you pressed Control – you’d decrease the font size (Command – on a Mac). But this created all sorts of problems. If text was inside of a fixed width container, like a div or a table, and the font size increased, the text would suddenly outgrow the container. CSS developed something of a reputation:

Coffee mug, with the text "CSS is Awesome" overflowing a containing boxBrowser makers changed directions, and instead of the zoom shortcuts changing the font size, they’d instead zoom the entire page. As the apparent font size increased, the containing element would increase size at the same time.

But you can still force your browser to zoom only the text. In Firefox, under the view menu, there’s an option to tell it to zoom text only. Here’s what our contact page looks like normally:

The Lane contact page, at lanecc.edu/contactHere’s what it looks like if I tell Firefox to only zoom the the text, and press cmd + four times (which confusingly zooms the text 300%):

The Lane contact page, zoomed 300%. Description follows in text.See where the issues crop up? Across the top, in our mega menu, the text gets to be bigger than the container. And again, in the twitter and events bar at the bottom, there’s a weird line across the middle (because we should have used a tiling image).

Despite those issues, our pages pass this standard easily. You’re allowed to use either text zoom or page zoom, and using page zoom our page looks great.

As always, a couple of tricky things:

First, if we had to support an old browser that didn’t support zooming (I’m looking at you, IE6), then we’d need to provide an on page method to change text size, usually using a big of Javascript. But here at Lane, we don’t support anything before IE11, so we usually don’t need to worry about this.

Second, mobile is tricky. Our website includes this meta viewport tag:

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no" />

But that can actually be problematic, as it prevents pinch zooming. But it turns out that some browsers (like Safari) don’t respect that meta tag. And other browsers support a “reader view”, which strips out a lot of styling to make the page easier to read on mobile. So while the WCAG recommends not including that specific meta tag, and we’ll likely remove it on the next iteration the Lane website, we’re probably fine for now because of the ready availability of workarounds.

Third, text on images should be avoided whenever possible. While page zoom will increase the size of an image appropriately, when you zoom an image it gets pixelated. Pretty much exactly unlike on TV:

This, along with the need to include alt text, is one of the reasons we encourage you to not use text on images on your pages.*

There are a lot of technologies where text zooming is more of an issue than it is on the web, like Flash or Silverlight, but since they don’t typically apply to the Lane website, we’re going to skip over them here. But if you’d like to read more about text resizing, you may also be interested in some of the techniques, which provides examples and more detail.

Interested in more? Check out the listing of all the posts in this series.

* For the super nerdy, SVGs are actually the exception to this rule, since as web ready vector images, they’ll zoom with the browser. But there’s no real convention for placing alt text on an SVG, so I’d encourage you not to use these yet either.

Understanding WCAG 2.0: 1.4.3 – Contrast

The next standard we’ll explore in our series on understanding WCAG 2.0 is 1.4.3, Contrast. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text:

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Low contrast ratios have been something of an unfortunate design trend recently. Before we get into what contrast ratios should be, let’s look at a couple of examples:


Black text on a white background. Simple. Classic. Easy to read. Here’s another example:


Yellow on white. It’s pretty obvious this is harder to read. But we can actually quantify just how much harder it is to read by calculating a contrast ratio. Getting the actual contrast ratio is kind of tricky, because color on screens is actually defined as a mix of three colors: red, green, and blue. The W3C provides a formula (at the bottom of this page), which calculates the luminance (a measure of the intensity of light) of the foreground color and divides it by the luminance of the background color to get a contrast ratio. But I found it easier to just use a calculator.

This blog doesn’t use a true black for the text, it uses a black with a little bit of white in it (because, as a rule of thumb, never use a true black on the web). So while true black on white has a ratio of 21, the ratio in our first example is 11.9, which easily meets our requirements. But our second example, which is yellow on white, has a ratio of 1, which is as bad as it gets.

To achieve AA compliance, we need a ratio of at least 4.5. But I find even 4.5 to be difficult to read, especially in a really bright room:

This line has a contrast ratio of 21:1

This line has a contrast ratio of 11:1

This line has a contrast ratio of 7:1

This line has a contrast ratio of 4.5:1

This line has a contrast ratio of 3:1

This line has a contrast ratio of 2:1

So we may want to consider always shooting for AAA compliance, which requires at least a 7. After a while, you kind of get a feel for contrast with black, white, and grey. But color is a lot harder. Let’s analyze a page on the website:

A screenshot of the top of the Lane community website.

There’s a lot of different color combinations there. When we designed the website, we tried to make sure we’d have sufficient contrast to make it readable by everyone. But we didn’t have any guidelines in mind, and just tried our best. It turns out it’s harder to judge contrast in colors.

Let’s start up at the top, on the four tabs for navigation to our different audience landing pages. The white on blue has a ratio of 7.4. But the yellow on blue for “The Community” has a ratio of just 3.8 – something that we’ll need to fix.

The banner had two surprises for me. I thought the white on blue would have fairly high contrast, but it was actually just a 3. While that’s on the edge, that’s actually sufficient here, because the text is considered large scale (at least 18pt, or a bold 14pt). I felt like the black text on the blue banner would have a fairly low ratio, but it’s a 7. So our banner checks out.

The announcements box has some troubles. The orange “Announcements” text has a ratio of just 2.3, partly because the background of that box is a little transparent, and partly because that orange is kind of bright. On the other hand, the linked announcement links are sufficiently contrasting, with a ratio of 5.5.

While I can fix the contrast on the website theme, this standard is part of the reason we encourage you not to change colors on your pages. In addition to not conveying information strictly through color, and keeping with the branding standards of the college, you need to make sure to keep sufficient contrast.

If you’d like to read more about color contrast, you may also be interested in these techniques, which provide examples and more detail.

Interested in more? Check out the listing of all the posts in this series.

2016 Archive Available

Every so often we take a snapshot of our website, to preserve exactly what it looked like, and simplify removing outdated content. While it’s important to prevent ROT, we also have an obligation to preserve a historical archive of what’s on our site. You can find the most recent site archive is available at https://2016sitearchive.lanecc.edu.

Unlike our current website, which is backed by a database, and which tracks even the smallest change to a page, the archive is a static set of HTML pages, and will not change further. While this means we’ll lose a little bit of history, we felt it to be a necessary compromise. Drupal, like WordPress of Joomla, is complex software, and to prevent security issues needs to be kept up to date and occasionally upgraded. HTML, on the other hand, isn’t interactive in the same way, and is mostly bulletproof. And, since it’s much simpler, it requires a lot less hardware to run.

The down side of these snapshots is that they will eventually decay. Links to external sites will go bad as other sites remove changes. Videos will be removed, and embeds will no longer work. But the content of our pages will stick around. So we can proceed less cautiously with removing content from the website, since to preserve it for the public all we need to do is link it to the archive.

If you’re interested in our last snapshot, from five years ago, you can visit https://2011sitearchive.lanecc.edu

Older snapshots are more limited, often just an image of the homepage. You can view them here:

Full details, along with further history and notes are available on the webguide pages.


Goals for 2017 on the web

There’s two months left in 2016, and the web team wanted to set a couple goals for the Lane website before we close out the year. An important part of our mission is to keep our pages as readable and relevant to our visitors as possible. One way to do that is to prevent and remove ROT – redundant, outdated, or trivial content on the web.

Redundant Content

Redundant content is dangerous content. If the same content appears in multiple places online, it’s only a matter of time until only one place is updated and the content is out of sync. Then we’re providing conflicting messages. Beyond that, redundant content makes it confusing for search engines to know which pages to serve. Pages are scored by search engines primarily by the number of other pages that link to them.

Here’s a (super simplified) scenario. Say we have two different places that describe our refund policies, and both of those pages link to the same page of meeting notes about changing those policies. Sites, both internal (on the www.lanecc.edu site) and external (including sites run by other organizations, but also places like moodle), link to a page on refund policy. But some link to the first place, and others link to the second page. When you search for refund policies, what do you get in your results?

We can’t be sure – and you might even get the PDF, because it’s getting some page rank from each of the two other pages. But if we had that content on just one page, everyone would link to it correctly, letting search engines value it correctly and making search better for everyone.

Outdated Content

That outdated content is an issue should be obvious, but even content that’s just several years old and no longer relevant can be an issue. We have 732 pages that haven’t been updated in over 4 years. Some of that content has certainly changed since then, and is now incorrect. It’s going to be a tremendous effort for us to go through and figure out which of those pages need updating, and which can just be removed.

Trivial Content

Trivial content is a difficult one. It might be content that you find really important – say, a photo album of an event a few years ago. But if that content isn’t helping the mission of your site and of the website as a whole and isn’t required to be there by law or by grant conditions, ultimately it’s trivial and should probably be removed..

Trivial content doesn’t need to be an entire page. Sometimes it’s just a line, like “Welcome to the Underwater Basketweaving Department!” that purports to make the department look friendly but falls flat. This excess content confuses search, and makes it dififcult for people to find what they need, ultimately leading people to feel like website is cluttered and difficult to navigate.

Long Content

We also have a problem with content length on our site. Sometimes pages are necessarily long, like COPPS policies (though there’s certainly some of those that could use help!). But often pages are so long they make it difficult to find what you need. Due to the way we store our pages, I don’t have an easy way to count words on pages, but I can count letters. These aren’t perfect counts, because they include some of the HTML that helps to style the page, but they’re a great estimate. I did a count of our pages last night and found some crazy pages: 50,000 characters. 80,000 characters. 90,000 characters. If we use an average of 6 letters per word, that’s as much as 15,000 words on a page! Positively insane. How can students find what they need?

Our Goals

As editors on the website, we’re enlisting you for help! Here’s the goals we’d love you to help us meet this year:

  1. Reduce the total number of pages on the Lane website by 5% (from 5768 to 5475).
  2. Reduce the number of pages with more than 20,000 characters by 20% (from 193 to 155)
  3. Reduce the average character count of our pages by 10.5%, from 4803 to 4300.
  4. improve the average age of our pages by 6 months, from roughly 24 months old to 18 months old.

Except for the total page count, these goals and statistics are actually calculated against what we call a “basic page”. So these don’t include news releases, COPPS pages, or the landing pages.

On December 1st, we’ll post an update with how we’re doing on each of the goals, then check in again on January 1st to see if we met them.

And of course, if you need any help getting back into editing your pages, let us know! Just contact Lori, Jim, or me and we’ll be happy to help.


Understanding WCAG 2.0: 1.4.2 – Audio Control

The third standard we’ll explore in our series on understanding WCAG 2.0 is 1.4.2, Audio Control. This standard is required for WCAG level A compliance, which is part of the level AA compliance that Section 508 requires. Here’s the complete text:

1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)

I wasn’t able to think of a place this applies on a Lane website, but I wanted to be sure to mention it. The only place we usually have audio play is on pages with video, and the embed options we have available on Lane pages make it difficult, if not impossible, for audio to play automatically. If you’re building pages for your class, or are doing some web development as part of IT, please be alert to this guideline.

Of course, I’m also of the personal opinion that we don’t want your site reminding everyone of mid 2000’s mySpace profile pages. You know the ones. You’d land on it to find a crazy, mismatched background and Nickelback playing with no way to make it stop. You couldn’t close the browser fast enough. Let’s not bring those days back.

If you’d like to read more about audio control, you may also be interested in this list of techniques, which provides examples and more detail.

Interested in more? Check out the listing of all the posts in this series.

Understanding WCAG 2.0: 1.3.3 – Sensory Characteristics

The second standard we’ll explore in our series on understanding WCAG 2.0 is 1.3.3, Sensory Characteristics. This standard is required for WCAG level A compliance, which is part of the level AA compliance that Section 508 requires. Here’s the complete text:

1.3.3 Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. (Level A)

As a mostly non-technical requirement, this one is actually pretty easy to understand, and it isn’t too different from a standard that’s already in section 508 (§1194.22(c)), which says you’re not allowed to convey information strictly through color. Standard 1.3.3 simply expands that requirement to cover visual and auditory impairments.

This doesn’t mean that you can’t convey information using some sort of sensory characteristic. You often should. If you have a button on a page to proceed to the next page, I’d encourage you make it look like a green arrow, and tell people to look for a green arrow right in the instructions. But you then also have to very carefully label the arrow as linking to the next page – you can’t rely on someone seeing green or being able to identify the arrow shape.

You also need to be careful referring to an element on a page by position. You can’t have instructions that say “Click on the link in the top right corner of the page”. But you can have instructions that say “Click on the link titled ‘College Catalog’ in the top right corner of the page”. Again, you need to provide an alternate method of locating that link. In this case, we’re using the link text.

The exception to this is above and below. In English, it’s generally acceptable to refer to content preceding the current reading position as being “above”, and content that follows to be “below”. Since your page should have sequence, you can usually refer to content above and below.

Here’s a final example:

Time 8 9 10 11 12 1 2 3 4
Underwater Basketweaving

Above, you’ll see a table with my schedule for this academic year. I’m not taking a particularly demanding schedule, but this way of presenting my schedule only conveys when classes are through color. So this doesn’t even pass existing 508 rules.

Time 8 9 10 11 12 1 2 3 4
Underwater Basketweaving

This one isn’t ok either. We’ve just traded colors for shapes. But you can probably see where this is going:

Time 8 9 10 11 12 1 2 3 4
Underwater Basketweaving

This one is probably ok, according to a strict reading of the guideline. But we could improve it further, by providing span‘s that are visible only to screen readers, which describe when the classes take place. We can’t be sure those symbols are readable by a screen reader either.

If you’d like to read more about sensory characteristics, you may also be interested in Guideline 96: Providing textual identification of items that otherwise rely only on sensory information to be understood, which provides an example and a bit more detail.

Interested in more? Check out the listing of all the posts in this series.

Understanding WCAG 2.0: 1.3.2 – Meaningful Sequence

The first standard that we’ll explore in our series on understanding WCAG 2.0 is 1.3.2, Meaningful Sequence. This standard is required for WCAG level A compliance, which is part of the level AA compliance that Section 508 requires. Here’s the complete text:

1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

In other words, if the order of the content on the page is important, you need to tell a screen reader the order somehow.

There’s a lot of ways to give content order. This blog post has order, for example. So far, we have a paragraph (a p element), a blockquote, then two more paragraphs. WordPress puts all of those a division (a div element). So the structure of this blog post is:

  1. div
    1. p
    2. blockquote
    3. p
    4. p

This blog post depends on sequence for the content to make sense – after all, if the paragraphs got switched, it wouldn’t make sense.

Screen readers use the order of tags on a page to automatically determine sequence. So if your page is mostly text and pictures, you probably already meet this requirement.

The problem occurs when there’s content which is visually in sequence, but whose actual representation isn’t in sequence. Imagine this scenario. You want to put two pictures on your page next to each other, with a caption on each one. You’re having trouble making it look right, so you decide to use a table. It’d look something like this:

A picture of a cat in a monitor A picture of a cat chewing on a monitor

Poof! It works, right? But tables can be read left to right or top to bottom, and the screen reader has no way to know which it should do. So, like most of us, it defaults to left to right, meaning it reads this:

  1. table
    1. A picture of a cat in a monitor
    2. A picture of a cat chewing on a monitor

See the problem now?

Ah, but wait, you say, what about alt tags? Don’t they label the picture?

Well, they would. But this is a circumstance where you want to have an explicitly empty alt tag – alt="". Because these pictures are captioned, an alt tag is redundant. If they had an alt tag we’d be reading the caption to them twice: once in the tag, and once in the caption. And also, even if we did want an alt tag here, that wouldn’t solve the problem.

Blind people aren’t the only people to use screen readers. Many people simply have really, really poor vision, and may be using a screen reader to help read to them. And while their vision is poor, it doesn’t mean they couldn’t still enjoy these cat pictures. The table above doesn’t let someone with poor vision associate a caption with the appropriate picture.

The solution is to use div tags, and set them to the left and the right side of the page. One easy way is to set your div tags to 50% of the width of the page, then set one to float to the left, and the other to float to the right (for the technically minded, you’d may also need to clear afterward). On our Drupal pages, you can use the classes “half left” and “half right” on div tags. Because we’re then grouping our picture and our caption inside of a div on each side, everything will be read in order.

Tables aren’t the only concern with sequence. Have a look at this list:

  • Head east on H St NWt
  • Turn right onto 13th St NW
  • Turn left onto Pennsylvania Ave NW
  • At the traffic circle, take the 1st exit onto 1st St NW

We recognize those as directions, right? But the bullet points are actually a problem. Those bullet points are considered an unordered list (A UL tag). Directions have a sequence. If we use bullet points, we haven’t told the screen reader what order to read the bullets in (it’ll probably know, but why risk it?). Instead, we need to use an ordered list (an OL tag):

  1. Head east on H St NWt
  2. Turn right onto 13th St NW
  3. Turn left onto Pennsylvania Ave NW
  4. At the traffic circle, take the 1st exit onto 1st St NW

You should also pay attention to div tags that are floated from the text. If you have an introductory paragraph that explains some topic, then a sidebar floating that provides clarifying points, you’ll want to make sure the clarifying sidebar is inserted into the HTML after the introductory paragraph, since understanding it depends on first reading the introduction.

If you’d like to read more about meaningful sequence, you may also be interested in Guideline 57, Ordering the Content in a Meaningful Sequence, which provides an example and a bit more detail. For complex layouts, you may also want to look at aria-flowto, which provides a kind of goto statement for text, to tell the screen reader when to jump over text that is out of sequence for presentation.

Interested in more? Check out the listing of all the posts in this series.

Updated Accessibility Requirements

An Update to the Update:

1/23/17 – The new 508 rules are out! You can read the announcement from the Access Board (on a website powered by Drupal!), or read my summary of the rules changes.

Original Post:

As people that maintain content on the web, we’re all responsible for making sure our content adheres to the Section 508 standards. However, as discussed in an earlier post, these rules are a little dated. Fortunately, the government is currently in the process of updating the rules, and a final rule could come any day – although the government has not been successful updating these standards in the past.

The new rules are likely to closely mirror the WCAG 2.0 standards, which are an international, consensus driven standard for accessibility for a wide range of technology formats, including web pages, Word documents, PDFs, and many others. WCAG 2.0 includes three different levels of compliance: A, AA, and AAA. It’s expected that the new 508 ruling will require compliance to the AA level.

During the next few posts, we’ll explore some of the ways the new standards differ from what we currently require of our Drupal pages. If you’d like a head start, you can view a complete comparison table on the Access Board website, which we’ll use as the basis to explore what’s different between 508 and WCAG 2.0.

One final note: although I’ll be writing these posts with a lens toward how it applies to our web pages, 508 rules apply to all the materials we create or purchase, including classroom materials. If you’re an instructor, you may want to get in touch the ATC for help ensuring your class materials comply with accessibility requirements.

All Posts in this Series

Twitter Cards and Open Graph

Across the Internet, Social Media now drives almost a third of all visits to pages. At Lane, that number is substantially lower: on our main website, it’s just 1%. One way to increase the number of people who click our links in social media (our click-through rate) is to improve our link copy and picture to make our posts more readily grab people’s attention.

This blog post is going to demonstrate two ways to do that. Though we’re going to be discussing ways to customize how your link is shared, we’ve set up defaults to improve how all pages look when shared, without you having to do anything at all. But a couple minutes of work will go a long way to making your shared link stand out.

Open Graph

The behemoth of social media is, of course, Facebook, so we’ll start there. Facebook developed a standard called Open Graph, which is a way to add hidden tags that tell Facebook, Google+, LinkedIn, and others how to share your page. Let’s take a look at what it looks like when we share a link on Facebook:

Facebook share window.

A similar preview box will show up when you share a link on LinkedIn or Google+.

If you’re a social media user*, you’ll now have an extra horizontal tab down at the bottom of your edit page, called “Megatags”. If you click on that, you’ll see two blue links: Open Graph and Twitter Cards. Let’s click on Open Graph and take a look.

Drupal Metatags tab. Relevant fields are further explained in the following text

Content Title

The first field in there, Content Title, is the only one that’s absolutely mandatory. Since it’s mandatory, by default we tell it to use the page’s title (that’s what [node:title] means).

A small digression: titles within Open Graph aren’t quite the same as titles on the Lane website. On the Lane website, we automatically add the department name and college name to the end of the title. So a page that says it’s title is “Contact” would actually have a title like “Contact | Science Division | Lane Community College”. That works no the web, where you want to show hierarchy. But in social media, that’s a title everyone is going to skip right over.

Open Graph titles are probably better thought of as headlines. Think back to that first picture we had – the title in that picture was “About”. That might be a good website title, but “About” is a terrible headline. We want something that’s going to catch people’s attention, and give them a reason to read a little bit further down. So let’s change it. We’ll instead use “Ready to learn more about Lane?”


The next field, image, is probably your best opportunity to get attention. Facebook will always pick an image on the page, but sometimes you can do better. If you’d like to tell a social network what image to use, add it in here. If you’re not sure how to find the full url for an image, get in touch with us by emailing webmaster@lanecc.edu.

We’re going to leave the image in our example alone, since Facebook chose a pretty good image for us.


Open Graph has one more important field, the description. But rather than ask you to type in a description all over again, we’re going to make use of a field that you may not have known you’ve had access to all along. If you’ve ever looked at the optional fields tab, you may have seen something like this:

Our optionl files tab, which included a field named 'search engine summary'

The search engine summary field provides a meta description tag, which Google and other search engines use as a snippet in search results. We use the same tag for Open Graph. If you’ve left it empty (like we have in our example) Google, Facebook, and others will create a description for you. Here’s what Google creates:

text is cut off, but reads: Lane offers many different educational opportunities–we truly have something for everyone! students by clock tower at main campus bus station As the third

The text in black is Google’s preview for the page. But it doesn’t make any sense –  “students by the clock tower” comes out of nowhere. That’s because Google is using the alt text from a photograph as part of the description. Let’s put in a new description so Google doesn’t do that. As a rule of thumb, you want a couple of keywords that people might be searching for, and you want to keep under 160 characters. We’ll use “Explore transfer and career & technical opportunities at Lane Community College in Eugene, Florence, Cottage Grove, and online”.

With those fields updated, here’s what the page will now look like when it’s shared:

Updated facebook post, featuring the text we'd talked about earlier

Better, right? Two caches. First, you’ll notice only part of the description showed up. That makes writing descriptions tricky. Facebook shows fewer characters than Google does. So if you can, keep the important parts of your description in the beginning. Second, after you make these changes, it takes Facebook as much as a day to recognize the updates. But you can force it, if you’d like. Enter the URL you’re going to share on Facebook on their debugger. Facebook will tell you when the last time was it took a snapshot of the page. If that snap shot is from before you made your changes, you can ask Facebook to crawl it again.

Twitter Cards

Twitter doesn’t use the same Open Graph standard that most other social networks use. Instead, it uses something called Twitter Cards. There’s two primary types of cards we’re interested in: the summary card and the summary card with large image. The only real difference between the two is the size of the image.

With the summary card, your image should be square, and a minimum of 120x120px. With the summary card with large image, your image should be rectangular, and at least 280x150px. It’s important you use as appealing of an image as possible, as it’s what’s going to make your post stand out best. By default, Twitter will use the Lane logo, but their guidelines state they don’t want the same image to be used repeatedly.

Setting up your Twitter card is much like setting up Open Graph. Click the Twitter card link, set the title and image, and make sure you’ve already set the SEO summary under the Optional Fields tab. Then, when shared on social media, you’ll see a card, like this:

Sample Twitter card, containing the text from earlier, in an attractive presentation on Twitter.

If you’d like a preview, you can use the card validator on the Twitter site.

One Caveat

For good reason, we don’t allow you to set these fields on pages you don’t control. So the editor of the science page can’t set the description of the math page. So if you’re going to be sharing a link for a page and you notice a problem with one of these fields, or you think the page could really use a better picture, email us at webmaster@lanecc.edu and let us know. We’ll take care of setting the meta tags to make sure everyone has a great shared link experience.

* Not sure if you’re a social media user? If you see an error message when you click on this link and log in, you’re not. But if you see a list of the sites you manage, you’re a social media user! If you’d like to become a social media user, check the Drupal dashboard for a list of upcoming training opportunities.


Click to Expand

A few days ago, an astute employee over in Enrollment Services pointed out that our steps to enroll pages weren’t completely accessible to the blind. This is an important problem, and a surprisingly tricky one.

The current legal requirements for web accessibility (including §1194.22, which we’re most interested in) are referred to as Section 508. These standards provide some useful guidance on how to help folks with an impairment of some kind. For instance, they describe how images should have an alt text field, except for when that image doesn’t support understanding of the content (e.g. a background or filler image).

On the other hand, these standards are now old enough to vote, meaning they’re older than Facebook, Twitter, selfie sticks, Google Chrome, iPhones, the Columbus Blue Jackets, and Windows XP. Needless to say, they’re showing their age.

There’s no way to make click to expand text accessible under current 508 guidelines. Our best option would be to duplicate the page and provide a text only version. Unfortunately, that could lead to a screenreader having to read a lot of unnecessary text.

The solution relies in the proposed new standards. These are still in progress, but the web community is confident they’re going to heavily include something called WAI-ARIA. WAI-ARIA provides a way to mark up your pages with extra attributes that screen readers know how to recognize, so the blind can better use interactive pages.

Returning to our original problem, starting this evening we’re now using the hide-show accessible plugin on those pages. This plugin lets you write some fairly simple markup in your page which will then get converted to a click to expand box like on the steps to enroll.

To use, you’ll first want to click the blue link below the edit box in Drupal that says “disable rich text”. Then, if you want a simple button with some text below it, you’ll want to paste this in:

 <p class="js-expandmore">Click on me</p>
 <div class="js-to_expand">
     here is the hidden content!

Then replace “Click on me” and “to show me!” with whatever works for your page. You’ll get something like this:

plus sign with some latin text that'd normally be clickable

And when you click to expand, you’ll see this:

minus sign, with the same text as before, but now with more text shown below it

If you’d like a little bit of color, you can also use an h3 element, which would place that text in an orange box:

    <h2 class="js-expandmore">Lorem dolor si amet</h2>
    <div class="js-to_expand">
       here is the hidden content

Exactly the same as before, but now it’ll look like this:

same plus with text, but now with an orange background

This is actually the more correct use – you nearly always want to use an h element of some kind when it describes the text after it.

For really advanced use, you can also add a full class to make the button full width. Or you can add the blue class to make the orange background blue instead. Or both!

    <h3 class="js-expandmore blue full">Lorem dolor si amet</h2>
    <div class="js-to_expand">
       here is the hidden content

would look like this:

blue background, full width, with same plus and text

This is definitely getting into advanced content editing in Drupal, so if you’re stuck don’t hesitate to contact us at webmaster@lanecc.edu.

Remember, we should always try to use the right tool. For instance, these kinds of show and hide buttons might seem like they’d be perfect for an FAQ. But we already have a different setup for FAQ questions, that takes care of alphabetizing and tracking changes to each question. And remember that many of the visitors to your page won’t bother clicking the button at all. Always spend time simplifying your content to make sure the important message is apparent even without clicking to show your other text.