Nathan J Pledger

I am often asked about Interfaces, and why should they be used. I do think that they are not used as often as perhaps they should, instead, people use a full blown class as a base that provides little value. I know when I was learning Java and C#, Interfaces were one of the more challenging aspects of the implementation of the OO rules as set down by Sun and Microsoft. Although fully conversant with OO, it was often quite difficult to really appreciate the value of an Interface. And then, one day ... it clicked. I think this is true for most people. I certainly so little benefit from Microsofts own documentation, I got a bit of an idea of their potential on the MS C# training course I attended but I became enlightened when working on a particular project with a particular configuration of classes.

So, although in many respects it is very simple, I thought it would be of value to summarise why I find interfaces useful. Hopefully, this will pop up on Google and help someone else achieve a higher level of coding-spirituality - and give me good Karma to boot!

Definition of Contracts

The core value of an interface is to define an interface to other objects that may interact with it. Browsing through the various collections will reveal three interfaces that are very useful: ICollection, IList and IEnumerable. These three classes define different functionality for any number of classes that implement them. An interface is nothing more than a "template" that - when provided to a function or object, can be used regardless of the originating type.

For example, I have an Interface that defines a SQL Portal, which may be used by different types of class for different types of database:

     public interface IDataPortal

     {

          string ConnectionString { get; set; }

          DataRow GetRecord(string tableName, IDictionary primaryKeys);

          DataTable GetRecords(string tableName, IDictionary criteria);

          DataTable GetRecords(string tableName, IDictionary criteria, string sortBy);

          IDictionary SaveRecord(string tableName, IDictionary primaryKeyHash, IDictionary dataHash, bool isNew);

          int DeleteRecords(string tableName, IDictionary primaryKeys);		

     }

Marker Interfaces

An Interface does not need to define any members, as is the case with the INamingContainer interface provided by ASP.NET. Developing a WebControl without this interface will generate HTML with names that cannot be guranteed to be unique and therefore are not supported by the server. Add the INamingContainer interface, and ASP.NET starts to output spurious ID's, which it can use to manage the state of a web page across post backs.

This is a snippet of the code I posted for the FormLabel control:

     public class FormLabel : WebControl, INamingContainer

Casting across Base Classes

To be able to use a set of classes as the same type of class, you would commonly use a base class. But sometimes there is no need to use a base class - and implementing a base class may have implications on the future maintenance of the class model. An interface implemented by one or more classes can provide the same purpose to allow casting across different types of classes and have them dealt with in the same way.

Extends Flexibility

By using a common Interface across a number of similar classes, it is possible to improve the opportunity to use different classes - but still use the same functionality. For instance, if a Property accepts a list, don't tie it down to an ArrayList and require that particular type of object to be used, use a common interfcae such as IList or ICollection that supports what you need in the property or function, but gives the consumer the flexibility to create a more logical object.

     public CopyListToSomething(IList iList, object something)

Hopefully this has provided some different uses for Interfaces. If anyone has any more, or disagrees, let me know ....

I have the need to create a clickable hierarchy of pages.  ie. You start at the top, and see the "root" folders, which you click to see the contents. You then click those to open their contents, and so on.

There are a number of options open to me, many of which I have tried and tested in various forms over the last couple of years. From a JavaScript-based tree to a series of nested DIV's with strategic CSS to create an indented effect.

But that ain't too good on the accessibility. So, how about creating them as an unordered list? Any group of links should be rendered as an unordered list (UL) to allow them to be grouped together. CSS can then be used to remove the bullets, align them correctly and even highlight the "selected" item.

The beauty of unordered lists is that they are naturally hierarchical. So by adding lists inside lists - a task very easily done - we can create quite a complex navigation structure using one of the simplest HTML tags - and be accessible to boot.

So, I created the code to build the lists, and it all looks good. Then came the overloading of CSS, replacing the bullets with images that would be more useful to the majority of users. But then, after running it, I was sorely disappointed.

As you can see in the screenshot, the images are vertically centred, meaning the visual hierarchy is completely lost. (The greyed areas have been added to provide some visual indication of the supposed hierarchy).

So, after playing around with various things it seems I cannot get the image to align with the text it is related to. I have a policy in my accessible work, in that I reduce the number of images on a page as much as possible. CSS is powerful enough to provide really impressive designs with the minimum of requirement for images. Where I cannot avoid images, I prefer to put the image into the CSS, so that the image doesn't necassarily appear on downlevel browsers and accessible browsers. This is particularly important for visual effects, which the folders in the screenshot clearly are.

By avoiding feeding the images into the HTML content, I can avoid:

• The image not appearing if the file behind it is missing
• The image not appearing if the user has turned off images
• An accessible browser highlighting the fact that an image is present, although it provides little function or added value to the purpose of the page content
• An image having to be loaded over a slower connection, such as a GSM or GPRS connection

So despite the extensive work W3C have done in helping facilitate an accessible and useful experience for users - even though the user agents may implement those functions in an apparent random fashion - it seems I am going to have to resort to an image within the text content.

Sheesh ....

One of the more challenging aspects of any persons use of a web page is the submission of form data. Whether that user is disabled, using a small device such as a form or using a fully-specced PC - none of us like filling in forms.

Now imagine that your filling in that form using a speaking browser like Jaws or a browser that cannot lay out your form to identify how it relates to the individual fields. A traditional form is set in a table, with labels on the left and fields on the right. It looks good, it is logical and is a widely accepted means of capturing user data. Apart from the fact that a table has been used for formatting, and not for data, we have the problem of what more relationship is there between the labels and the fields than sharing a common table row?

The <label> tag overcomes this, and is typically written thus:

<label for="txtUsername">Username:</label><input type="text" id="txtUsername" name="txtUsername" />

Using this, the label for Username can be placed anywhere on the page, though this is obviously of limited use. A speaking browser will identify to the user the purpose of the textbox by reading something like " text input, Username " instead of what would otherwise be something next to useless, such as " Text input ".

Now put this in a usercontrol inside ASP.NET and we see that the ID applied to the input is mangled with ASP.NET's hierarchical naming convention.

<label for="txtEmailAddress">Email Address:</label><input name="Basket_LoginClient0:txtEmailAddress" type="text" maxlength="32" id="Basket_LoginClient0_txtEmailAddress" />

They don't match!

Creating an Accessible LABEL control in ASP.NET

Create a new WebControl, with the following simple code:

One of the more challenging aspects of any persons use of a web page is the submission of form data. Whether that user is disabled, using a small device such as a form or using a fully-specced PC - none of us like filling in forms.

Now imagine that your filling in that form using a speaking browser like Jaws or a browser that cannot lay out your form to identify how it relates to the individual fields. A traditional form is set in a table, with labels on the left and fields on the right. It looks good, it is logical and is a widely accepted means of capturing user data. Apart from the fact that a table has been used for formatting, and not for data, we have the problem of what more relationship is there between the labels and the fields than sharing a common table row?

The <label> tag overcomes this, and is typically written thus:

<label for="txtUsername">Username:</label><input type="text" id="txtUsername" name="txtUsername" />

Using this, the label for Username can be placed anywhere on the page, though this is obviously of limited use. A speaking browser will identify to the user the purpose of the textbox by reading something like " text input, Username " instead of what would otherwise be something next to useless, such as " Text input ".

Now put this in a usercontrol inside ASP.NET and we see that the ID applied to the input is mangled with ASP.NET's hierarchical naming convention.

<label for="txtEmailAddress">Email Address:</label><input name="Basket_LoginClient0:txtEmailAddress" type="text" maxlength="32" id="Basket_LoginClient0_txtEmailAddress" />

They don't match!

Creating an Accessible LABEL control in ASP.NET

Create a new WebControl, with the following simple code:

using System;

using System.Web.UI;

using System.Web.UI.WebControls;

using System.Web.UI.HtmlControls;

using System.ComponentModel;



namespace Duke.Lib.ASPNET.Accessibility

{

     [DefaultProperty("Text"),

     ToolboxData("<{0}:FormLabel runat=server>"),

     ParseChildrenAttribute(false)]

     public class FormLabel : WebControl, INamingContainer

     {

          private string _friend;

          #region ~ Properties ~

          public string Friend

          {

               get { return _friend; }

               set { _friend=value; }

          }

          #endregion



          public FormLabel() {}

          protected override void CreateChildControls()

          {

          Control control=(Control)Parent.FindControl(_friend);

          HtmlGenericControl label=new HtmlGenericControl("label");

          if (control!=null) label.Attributes.Add("for",control.ClientID);

              else label.Attributes.Add("for",Friend);

          foreach (Control childControl in this.Controls)              label.Controls.Add(childControl);

          this.Controls.Add(label);

      }

   }

}

Then, refer to your new control using the Register directive showb below, at the top of the page:

<%@ Register TagPrefix="ProgramX" Assembly="ProgramX.Lib.ASPNET" Namespace="ProgramX.Lib.ASPNET.Accessibility" %> 

(Obviously your namespaces, assembly name will be different)

When you need to attach a label to a control (any control), add the following code: 

<label friend=”txtEmailAddress” runat=”server”>Email Address*:</label><asp:TextBox id=”txtEmailAddress” runat=”server” />

This will attach the labels "for" attribute to the name of the control in the FormLabel's "friend" attribute. 

Further

The LABEL method is also useful in CSS, as you can now specifically target labels without having to place them inside a containing SPAN. 

Just putting these labels next to your fields doesn't make your form accessible! Rule #1 in accessibility is: everyone is different and no rule is a rule. People have different needs and different preferences. Make sure your labels are consistent with the purpose of the field and use simple language. And never use a "negative selection", which would be something like:

"Do not sign my up to newsletters"

This should be "Sign my up to newsletters" with a default selection of checked if you insist on going down the route of capturing the maximum number of users for your mailing list.

You'll notice the '*' character at the end of the label, thats not accessible, thats just common sense to identify a mandatory field. Consider that when you use such indicators, that the lowest common denominator is always better - which means a character rather than a graphic. Its faster, it works on every platform and if you need to make it fancy, just use CSS.

Finally, form controls should be placed inside a FIELDSET tag, which can at times be challenging to make look anything near decent, so I'll doubtless cover that again later.

Comments turned off due to spamming.

... standards are being ignored, common decency in design is abandoned and .NET is rampant.

Let me take a second to introduce myself. A "Manc Manx", I moved to the Isle of Man from the great city of Manchester, UK. Having left Salford University in 2001, I have worked for a number of companies including one specialising in collective purchasing and e-billing, one specialising in web design and accessible web sites for the NHS and now for a major Powersport company that operates from the "Home of Road Racing", The Isle of Man.

From the depths of VB6, to the heady heights of ASP.NET with C#, I have had the opportunities to find my niche, which is accessibility and web standards.

Why Accessibility is Important

Accessibility is not just about letting disabled people use your site. It is about taking the time to consider those with other browsers, other platforms and other footprints. Loading a site with widgets, blinkies and tickers is not, in my opinion, a great step in creating an attractive and stimulating site.

Web Designers often fall foul of basic gotcha's in poor site design:

• Use of tables for formatting
• Use of tags for styling instead of what they actually mean, eg. heading tags should start from 1 and increment - not jump.
• JavaScript is all very good, but it is a pain to get to work on all browsers and if it provides functoinality, rather than complements it, then people lose out.
• Reliance on poor standards implementation by a certain browser - and forget anyone else!
• .... and when the rules have been broken, achieving immunity by adding "This site is best viewed at 800x600 in MS Internet Explorer v6", with a big button to download the latest version!

I will doubtless evangelise about these points and more as and when I find the time.

This blog will probably name and shame sites that are not up to scratch, it will spout personal opinions that will probably be entirely unreliable but I think it needs to be said.

Thanks for stopping by, hope to see you soon ....