WWW Subdomain Makes The FQDN

Using WWW or no-WWW for web addresses sure seems to be a personal preference. I prefer to not use the www to keep things simple. Less to type, yah?

But, by leaving off the “www” in typing in a webpage address, we’re having to make an assumption or rather your browser has to figure something out. What’s the host?

Other people can’t seem to find a website unless they use the www — like they think it’s mandatory to use it. But, when there’s a different subdomain, like mail or demo, the www usually isn’t warranted.

So, what the heck is FQDN and why do we need it? It’s a question that may pop up when you’re about to install some “goody” on your website.

FQDN? It stands for Fully Qualified Domain Name which is to say a complete domain name or an absolute domain name.

FQDNs require a hostname plus a domain name.

The domain name is the web address you purchase, like sitepoint.com or wordpress.org.

The hostname is the prefix or subdomain for a web address, like www or mail or demo.

Splicing the hostname to the domain name gives one the FQDN.

Examples of fully qualified domain names:

  • www.ebay.com
  • mail.ark.edu
  • demo.oba.net

The domain bbc.com isn’t complete because we don’t know the hostname. Granted, most browsers and people will assume the hostname to be ‘www’, but you know what they say about assuming anything. ๐Ÿ™

When specifying a FQDN we lose the ambiguity because the exact webpage location has been spelled out. There’s no guessing involved and that’s a good thing.

When installing a package on your server or computer you might be asked for the FQDN and now you know what that means!

The Main Points: Using a FQDN is the same thing as specifying a complete web address. FQDNs consist of a hostname plus domain name. A hostname is often assumed to be ‘www’ but it can also be the name of a server, like ‘mail’, or another subdomain like ‘demo’.

Section 508 Standards Improve Site Accessibility

Interested in improving site accessibility for all site visitors? The section 508 standards were written to assure that everybody can see your site, including people with vision and cognitive disabilities. Once you’re familiar with these standards, it’s not too hard to abide them. Why wouldn’t we want to have the broadest audience possible anyway?

What are these 508 standards and why do they exist? The United States Federal government put out an edict – ok it’s a law – that states that any federal website must be created in such a way as to allow everyone to “see” it or otherwise consume the information.

The main idea was to make sure to include folks with disabilities who might use alternative means of navigating the Web and to assure that anyone and everyone has equal access to the government. Every web page created by the federal government is checked against the following standards for compliance before being published.

Here are some suggestions on how to meet the standards (a – p) of Section 508 of the Rehabilitation Act, ยง1194.22. Be aware that the standards have been paraphrased for the most part and that this is only one interpretation on how to meet these standards.

Section 508 standards and how to meet them

a. Provide a text equivalent for every non-text element.
Use the alt attribute for every image or embedded media to explain what the media is portraying. Complex graphics may require a link to a new page for full explanation. Images that allow for interactivity must have their functionality explained, too. Audio content needs to be captioned or have transcripts provided. Graphics used for decoration, like borders or background color gradients, can have empty alt tags.
b. Multimedia presentations need to have their captions or transcripts synchronized with the presentation.
Videos without audio tracks should have audio descriptions created. Caption synchronizing can be accomplished with any media player using MAGpie, the “original free caption- and audio-description authoring tool for making multimedia accessible to persons with sensory disabilities.” It can also be used to create caption files for YouTube videos.
c. Information that is communicated with color must also be communicated without color.
Color cannot be the only means of communicating information. People who are color blind may not see links if they’re not underlined or highlighted in some other way. Contrast must be high in order for others to see the message.
d. Webpages need to be readable on their own, as if the stylesheet was missing.
Even though most web pages would look very plain without their associated stylesheet, they should be organized so that they’re readable without the stylesheet.
e. Text links should be provided for each active region of server-side image maps.
Use client-side image maps instead of server-side image maps. Each active region should be described in alternative means.
f. Client-side image maps should be used instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
Use client-side image maps instead of server-side image maps. Each active region should be described in accessible text.
g. Data tables need to have row and column headers described.
Use <th> in data tables. Don’t use tables for layout purposes.
h. Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
Use the scope attribute to tell the browser or screen reader that everything under a column heading is associated with that column or that everything to the right of a row header is associated with that row. Complex tables should use ids or headers. Avoid spanned rows and columns and instead present the data in more simple terms.
i. Frames should have text for identification to describe the navigation.
If you can’t avoid the use of frames, make sure they have descriptive titles.
j. Assure that images do not flicker at a frequency greater than 2 Hz and lower than 55 Hz.
Avoid using flickering images.
k. If there is no way to provide accessible or alternative content for your message, a text-only page must be provided.
Keep things simple, but if that’s not possible make available text-only pages. Keep each text-only page up-to-date.
l. When using scripts to display content or create interface elements, assure that the same information is provided via functional text that can be read by assistive technologies.
This is going to require some thought for every instance of jQuery or other javascript components on a page.
m. When a web page requires a plug-in to interpret the page content, an accessible link for downloading each plug-in must be provided.
Download links must be provided for the plug-ins required to read PDFs or to view Java applets, for example.
n. Help people using assistive technologies to fill out your online forms.
Use <label> tags with the for attribute for each element of a form. Use descriptive titles and provide instructions on how to properly fill out the form.
o. A method should be provided that allows users to skip a series of navigation links.
Use skip links to let users pass the navigation menu and go directly to the content. A skip link is a link at the top of the page that plainly states that it ‘skips navigation’ or ‘skips the link list’ and jumps the reader to an anchor at the beginning of the content.
p. When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
Allow the user to have control over the timing of inputs.

So, the bottom line is to keep things simple. Use text to describe things on the page and to identify things that aren’t text. Be careful with scripting actions so that information is accessible to all.

In an effort to improve the status quo I’ll be taking a look at all my web properties with an eye for improving their accessibility. Do you have any hints on how you’ve accomplished the same?

Speed Testing WordPress Sites

Links are plentiful on the ‘Net and these are a few that will help when speed testing your WordPress sites.

Site Loading Speed, Caching and Validation

  • Pingdom Tools tests the load time of URL, analyzes it and helps to find bottlenecks. Click on down-arrows for each file/path under the waterfall tab to see the headers and again for each recommendation under the Performance Grade tab for specifics.
  • Yslow, a browser plugin analyzes web pages and suggests ways to improve their performance.
  • W3 Total Cache is a superior caching plugin for WordPress sites.
  • Firebug Web Development Tool check Net tab for page element loading times.
  • Check out your site’s speed with this handy speed test.
  • Page Speed test online or via browser extensions for Firefox and Chrome. Results include minified HTML, CSS and JS files saved to configurable directory.
  • Caching Tutorial explains web and proxy caches and http headers.
  • REDbot checks the server clock and caching for a site, hover over each line of the response for full explanation.
  • WP Tutorial on Boosting Site Speed excellent step-by-step tutorial showing how to use plugins to improve speed of WordPress sites.
  • WebPageTest checks page loading speed, can select various browsers with screen shots reported. Advanced settings allow selection of connection speed for DSL, Cable, FIOS or 56K dialup.
  • W3C HTML Validator finds out if your pages don’t validate, which can make them slow to load.
  • W3C Link Checker
  • Test Mobile Readiness of web pages.

Site Accessibility Resources and Tools

The accessibility of a website must be directly proportional to the percentage of viewers who can actually see, read or hear the content. After all, if people can’t observe it, how are they going to get your message?

Since web developers don’t need to adapt the coding of sites for the majority of us to see the content, it may not come natural to them to include those who do need special consideration. It does take a little bit of extra time and thought to accommodate – or dare I say be helpful to – people with vision difficulties or those who use screen readers to use the Internet.

To get an idea if your sites pass muster, visit the accessibility links below for a little help.

Links for Accessibility

HERA accessibility testing provides reports that show exactly where a site should be improved. If any errors are found when your site is scanned, they’re clearly highlighted so that you can take corrective action. A really helpful part is the ‘Navigate by guidelines’ feature, where results are categorized by the accessibility guidelines. Stepping through the results under each guideline will show you exactly which parts of your site aren’t accessible, and it will help you learn more about the guidelines.

WAVE Accessibility test shows icons on the test results page where the guidelines weren’t met. Icons were extremely helpful in determining what parts of the page weren’t up to snuff. One feature to highlight is the ‘disable styles’ button in the upper right of the results screen. Click that button to see your site without style sheets applied. If your content can be read without too much trouble, then it’s probably ok.

Readability test provides results of three algorithms in judging the readability of text on the page. If your site deals with a technical subject, or if your content is too complex for the average Joe to easily understand, your site may not fair well on the readability tests. Keep in mind that Joe Public only reads at an 8th grade level. Sad, but true :(.

CSS Analyzer won’t give output until all CSS errors are corrected. It’s just not possible at this stage with WordPress sites due to partial implementation of HTML5.

UI Test Enter your URL at Site Test for handy direct links to accessibility and validation checkers. Very helpful when modifying a page to meet accessibility guidelines.

The guidelines we’re talking about are the Web Content Accessibility Guidelines (WCAG) and the portion of U.S. Law for Section 508 which requires that information technology is accessible to people with disabilities, at least in federal agencies.