U.S. Department of Energy - Energy Efficiency and Renewable Energy

EERE Communication Standards & Guidelines

Linking to Native File Formats and PDFs (Text Version)

Below is the text version for the seventh podcast in the Introduction to Standards Podcast, Linking to Native File Formats and PDFs.

Welcome to the Introduction to Standards Podcast. I'm Elizabeth Spencer, and today I'll be talking about how to link to native file formats and PDFs. You can find this information by going to "Web Technical Guidelines", then to "Coding," and clicking on "Native File Formats and PDFs."

First off: Native file formats. What do we mean by that? Well, a native file is, well, a file. It can be a Word file, a PowerPoint, a Text file, whatever—if it isn't a Web page, then it's a native file. So this podcast is basically about "linking to anything that isn't a Web page."

This sounds easy—and it is, really! You just need to know that linking to a file is a little different than linking to a Web page.

Basically, we need to make sure our users know what we are linking them to. It's very natural and easy to link people to a Web page—they can use their "back" button to get back if they need to, and they have an idea of how the page will work.

But you can't link blindly to anything else. It's jarring when a user wants to click on a link to get more information, but then, instead of getting a page, they get asked to download a file. What if they can't download that file type?  What if they don't have the right software? What if you're linking to a format that works well on Windows machines, but is more tedious on Macintoshes, like a Windows Media File? What if the users don't have the right plug in for their browser, and instead of opening a file it asks them to download it?

Basically, everyone can read a Web page. But once you start linking to files, you have to warn the user that they are files, because there's a risk that they can't download that file or that they don't want to.

So! How do you link to files?

Well, most files are really easy now. PDFs, Word files, PowerPoints, and Excel files are handled for you now. Just link to them like you would to a Web page.

The difference is this:  When your page goes live, an icon will appear after those links. That icon tells users that those links point to a file, not to a Web page. The icon is linked and includes alt text that tells users with screen readers that these are files. (That helps them decide to click on it or not, because it's much more disorienting to have a program open up on top of your browser when you're using a screen reader to navigate.)

These icons are added automatically to pages in OpenText or on the National Renewable Energy Laboratory's servers. If you're working on a site that isn't in either of these hosting environments, you'll need to code the icons by hand. The code for that is on Communication Standards.

But what do you do for all other file types?

Well, for all other native files, you have to spell out what you're linking to specifically. This helps users know what type of file you're linking to, which helps them decide if they have the software to download it. It also tells them the file size, in case the file is larger than they want to download. So let's say that you're linking to a ZIP file. You might say:

View the full collection of photographs (ZIP 50 MB).

With "full collection of photographs (ZIP 50 MB)" linked. You want the title of the file—or a description of the file—linked as well as the file type and size. This helps users with screen readers.

The reason you don't want to link just the "ZIP 50 MB" is because users with screen readers can choose to skip around a page and only listen to the links, and not the words around them. So if you only have the size linked, all they'll hear is "ZIP 50 MB," which doesn't help them decide to download it or not.

And, in case the user doesn't have the ability to open that type of file, you should include—after the link—a link to a free program that can open that type of file. So if you link to a ZIP file, you should include a link after it:  Download WinZip.

So when you link to EXE files, ZIP files, Windows Media files, or other native files, you should spell out the link like this.

When you write those links, do it like this:  File extension first, then the size in kilobytes or megabytes. For kilobytes, just round to the nearest whole number—you don't need decimals. For megabytes or gigabytes, round to the nearest tenth of decimal—So you'll have, for example 750 kilobytes, or 3.2 megabytes.

And now for a technical note!

Remember your directory structures. Keep files in the /docs/ folder. PDFs should go in the /pdfs/ folder. Videos go in your /media/ directory, unless they're in the video skin, in which case you should read up on the video standards. Or you can wait until the next podcast! But if you have a Windows Media file or something else that's not in the skin, it can go in your own /media/ directory.

And that's it! If you have any questions, please write the Communication Standards webmaster or leave a comment on the Communication Standards blog. I'm always glad to help!

In our next podcast, we'll be talking about video standards—how to format videos, how to post them, and how to handle YouTube. So see you next time!