Blog entries about web design & development, our clients, our projects, our company, and more

Website Front-end Quality Control Considerations

Posted February 05, 2008 @ 12:31 PM, by Marc, in HTML, Quality Assurance — 0

Every good web agency practices some form of code-based quality control during the creation of their clients’ websites. For example, development is paused for a short amount of time every few of days/weeks/months and the code that has been written so far is tested to ensure it meets certain standards defined by the agency. These tests can include anything from checking the security of the database to determining how a visitor who is color-blind might interpret the design. Since we specialize in design and front-end development, there are a few things that we always test to help ensure a good user experience for visitors and to reduce inconsistencies among many common web browsers.

Adjust the font-size

It’s common practice to think of how a layout will change when more content is added to it, but few people consider how the layout will change when the existing contents’ font size is increased or decreased beyond the default size. It’s critical to perform this test because somebody is bound to increase their font size due to impaired vision or being confined to a smaller monitor than they prefer:

To adjust the font size in Firefox on Windows

Keyboard shortcut: Ctrl++ (plus) to increase, Ctrl+- (minus) to decrease, Ctrl+0 (zero) to reset to default

Menu: View > Text Size > Increase or Decrease

To adjust the font size in Firefox and Camino on OS X

Keyboard shortcut: Cmd++ (plus) to increase, Cmd+- (minus) to decrease, Cmd+0 (zero) to reset to default

Menu: View > Text Size > Increase or Decrease

To adjust the font size in Internet Explorer 6

Menu: View > Text Size > choose an option

To adjust the font size in Internet Explorer, versions 7 & 8

Menu: Page > Text Size > choose an option

Note: If you use the keyboard shortcut Ctrl++ (plus) or Ctrl+- (minus) in Internet Explorer 7 & 8, it zooms in on the web page and doesn’t represent an increase or decrease in font-size. This particular action should not be used to determine how Internet Explorer 7 & 8 handles a change in font size

To adjust the font size in Safari on OS X and Windows

Keyboard shortcut: Ctrl++ (plus) to increase, Ctrl+- (minus) to decrease

Menu: View > Make Text Bigger or Make Text Smaller

To adjust the font size in Opera on OS X and Windows

Opera doesn’t have a method that allows the user to increase the font-size. Like Internet Explorer 7 & 8, if you use the keyboard shortcut Cmd++ (plus) or Cmd+- (minus), it zooms in on the web page and doesn’t represent an increase or decrease in font size.

Put each unique page through a few online validation tools

By validating each unique page you are presented with a quick and understandable list of any errors or warnings that exist in your code. Correcting those errors and/or warnings can result in layout issues being fixed, CSS/JavaScript issues getting back into proper working order, and inconsistencies across multiple browsers being reduced or eliminated altogether. It’s a very valuable way to ensure that the page is marked up properly and can considerably reduce the time spent on changes and/or trouble-shooting inexplicable bugs in the future.

• http://validator.w3.org/: This service validates the HTML that is rendered by the visitor’s web browser
• http://jigsaw.w3.org/css-validator/: This service validates the CSS that is rendered by the visitor’s web browser
• http://www.contentquality.com/: This service allows you to validation against multiple accessibility requirements (Section 508 and WCAG Priority 1/2/3)

The last validation tool, above, will test your page for accessibility errors. These types of errors won’t break your layout, but attention to them will ensure a better experience for a larger audience and that is never a bad thing.

Form accessibility

Forms are one of the Internet’s few necessary evils due to our need to enter unique information coupled with the limited options of input devices. You can do your part to ensure a visitor’s experience with your form is as satisfying as possible by testing a few of its characteristics:

• Check the tab order on forms: If you click your mouse in/on the very first form input to give it focus, then continually press the Tab key, does the focus move in an order that a visitor would expect, or does it jump around out of the expected flow? A properly written form is usually devoid of this problem, but sometimes your hands are tied and you must work with form inputs that are placed out of order in the markup. This can be temporarily solved by using an attribute called tabindex on each input, like so: <input type="textbox" name="emailAddress" tabindex="3" />. I said “temporarily solved” because correcting the actual order of the form inputs, within the markup, should be on your to-do list
• Form labels: Every form input that has associated text should utilize the label element, like so: <label for="emailAddress">Your email address:</label> <input type="textbox" name="emailAddress" id="emailAddress" />. This provides two great benefits:
  1. The semantic value given to the form is increased, allowing screen readers and other assistive devices/software to clarify the form’s content to a visitor who is using such devices/software
  2. The visitor can click on the text in the label element to give focus to it’s associated input. Here’s an example – click on the phrase “Your email address,” below, and notice how the cursor appears inside of the input box that’s next to it:
     Your email address:
• Form fieldsets: Any group of form inputs that are related to each other should be placed inside of a fieldset element. Additionally, this fieldset should include a legend element to name this related group of form inputs. Although it’s rarely desirable from a design standpoint to see the fieldset and legend rendered on-screen, they serve important semantic roles and they can easily be hidden with CSS. Learn more about form fieldset and legend elements

Form input and validation

When a form requires that information be entered in a certain format for some/all of the inputs, you should make every effort to clearly notify visitors of these requirements. They are more likely to fill out the form the correct way on their first attempt. If the visitor still misses an input, or enters information in an incorrect format, you can fix their formatting errors and/or notify them of their mistake(s):

• Wrongly formatted information: If an input requires the visitor’s information be a specific format or length, such as phone numbers and email addresses, it’s necessary that one of two things are done to ensure a satisfying experience for them:
  1. Make sure that nothing but the precisely formatted information is accepted, but you need to clearly explain what is expected. For instance, use a small example placed next to the input’s label, like this: “Your 10-digit phone number: (ex. 555-555-1234) [input box]”
  2. You allow them to enter their information in any reasonably common format they’re comfortable with, then use extra code to change the format of the visitor’s information in a way that’s meant for the database, such as removing dashes and spaces or adding expected values, etc.
• Inform the visitor which inputs are required: This is somewhat of a no-brainer, but I do have one piece of particular advice to give. When you intend to inform the visitor that some inputs are required, whether using an asterisk or any other form of notification, do consider the quantity of inputs that are required versus the amount of inputs that are not required. If a majority of the form’s inputs are required, it’s more pleasing to inform the visitor which inputs are not required. This results in a form that has less content sprinkled all over it
• Inform the visitor what input(s) they forgot to enter information into: When a visitor forgets to enter information in a required input, it’s necessary to inform them which inputs were missed. In the old days of the Internet, it was common to present a list of missed inputs in a JavaScript popup or in a separate section of the web page, but this type of response is now frowned upon because it forces the visitor to look around an unchanged form for the inputs they missed. It is better practice to highlight the missed input itself, whether by using a contrasting background color, border color, or label color, allowing the visitor’s eyes to quickly go to the missed input(s) without having to search

Other general considerations

• Alt attributes: Every image not presented via CSS, whether inserted as a standard <img /> element, or placed in a form button such as <input type="image" src="xxx" />, must have an alt attribute. The value of the alt attribute must describe the contents of the image and nothing else. If a client dislikes how Internet Explorer incorrectly displays the alt attribute’s value as a tool-tip when hovering over the image, it can be band-aided by inserting an empty title attribute. Doing this will stop Internet Explorer from displaying the alt attribute’s value as a tool-tip. For example: <img src="path/to/image.png" alt="A photo of three office buildings" title="" />
• Hovering: Nearly every object that a user can click on should visually change when hovered over. Simply put, when a person moves their mouse cursor over something that can be clicked on, it should change its appearance to indicate that it’s clickable. Whether it’s a text element that shows an underline or an image that swaps its source, the person should understand immediately that the object they’re hovering over can be clicked. On the contrary, many types of input elements rarely have to conform to this rule; a select element and a submit button, for instance, don’t need a hover-state change
• Anchors that link to media files: Whenever an anchor (text or graphic) links to a file that isn’t another web page, it’s important to inform the visitor that they’re about to open or download a particular file type. For instance, when a bit of text says something such as, “Read this press release”, the visitor might think that they’ll visit another web page containing the press release. Instead, it links to a PDF file and the visitor is now stuck waiting for the PDF to download and/or open. It’s always important to inform the visitor that they’ll be requesting a PDF file (or any other type of non-web page media) before they click on it. Common practices could be:
  • If the anchor is used in body text, this works well: “…our recent October press release (pdf) outlines our strategy for the coming year…”
  • If used in an image-based button, it’s convenient to place a small PDF logo in the graphic
• Proper use of character entities: I won’t get into character entity specifics in this article, since I wrote a separate article about them already. Head over to the article to learn more about these little gems of HTML and be sure to use them regularly in your body content: Character Entity References are your Friends
• Flash loading graphic: When a Flash movie is used in a website it should always utilize a loading graphic. Even if you consider the movie file small, there is a chance someone with a slow internet connection will visit the web page and they deserve to know that the big blank space they’re staring at will eventually contain something worthwhile. Without any sort of loading graphic, they might think the page is missing some content and move on; the loading helps to ensure they stay on the page while the movie is loading

This article is an official never-ending work in progress. I don’t consider it nearly comprehensive enough or as accurate as it could be and I’d love it if you would leave a comment and tell me what other considerations you keep in mind when designing and developing the front-end of a website.

---

---

---

• Previous: Mobile Phone Web Design and Development Considerations
• Next: Receiving Unique Payments with PayPal