Following on from the previous post, we now move on to Data Formats and Data Generation.

The system can play music in up to 8-part harmony, equivalent to 8 separate parts or voices in a choir, and keeps track of the current status of each part. The numerical data for each piece of  music are arranged in groups to represent events at successive points in time. Each event usually involves changing the note being played by any one or more of the parts, including muting any of the parts. Following are some examples of three typical events:

• Starting at address 193 is the Data Group for a chord, duration 21 time units.
• The Control Byte at 194 has value 180 = &B4, which has 4 bits set (7, 5, 4, 2).
• The voices corresponding to bits (6, 3, 1, 0) will remain unchanged, whatever their previous states.
• Address 199 holds value 131 = &83, which represents a mute of all voices, duration 3 time units.
• Address 200, 201 hold the sequence 00, 08 which represents the bar line at the start of bar 8.

The data group for each event begins with a Duration Parameter, D, a 6-bit number in the range 1 to 63 which defines the length of time that the note or chord in question is to be sustained.

The default value of D is 24 units for a crotchet, 12 for a quaver, etc., although these values are arbitrary – but the inclusion of a factor of 3 facilitates the rendering of triplet rhythms when required.

Next comes an 8-bit Control Byte which acts as a mask defining which part or parts are to be changed. This is followed by a list of N numbers, each in the range 0 to 54, representing the notes to be played. N is the number of set bits in the mask and the sequence of note-numbers defines to which parts they are allocated.

The note value zero indicates that the relevant voice is to be silenced. A Duration Parameter in the range (1 to 63) + &40 indicates that the previous chord is to be maintained unchanged for a further period of time (a tie). A parameter in the range (1 to 63) + &80 heralds a mute, a period in which all parts are to be silenced.

A Duration Parameter of zero represents an Escape Code which is followed by at least one further byte. If this next byte is a number in the range 0 to 240 (&F0) it indicates a bar number in the music – this is ignored by the playing program but is an invaluable aid to editing the data. Values from &F1 to &FF invoke various special functions and may be followed by additional bytes. These functions include setting the Tempo Parameters, marking the beginning and end of repeated passages, implementing octave- and pedal-coupling facilities and marking the end of the piece.

Generating The Data

In the early days, the data lists were compiled and entered into memory manually, which was extremely tedious even for short and simple melodies. Around the same time, Dad was writing a PC-based program originally designed merely to print music in a legible form, and it occurred that it might be possible to combine these two problems. Now, generation of the data begins with a Project in Visual Basic running on a PC under Windows 98. Please stop laughing, there are good reasons for using this ancient machine!

[Left - the PC-based Visual Basic screen for inputting music - very much "me-ware"! - click image for bigger version if you dare]

The programme initially displays a pair of blank staves, plus, in the case of organ music, an additional stave to show the pedal part. Notes are inserted by a series of mouse-clicks to build up a single line of music.

The information displayed is stored in memory merely as the note-values and their co-ordinates on the staves, and each line of music can be saved as a .DAT file. No bit-image files are involved.

The N lines of music  required for a given work can be printed out for future reference. The filename for each line of music is constructed from the file-stem, Plus the bar number at the start of that line, thus Bday1.DAT and Bday5.DAT.

About The Voices

The treble clef (normally played by the right hand) contains the Soprano part (tails up). Alto (tails down) and an extra intermediate part (X, with no tails).

Similarly the next stave down (bass clef, normally played by the left hand) supports Tenor (tails up). Bass (tails down) and an additional part (Y, no tails).

When the music has been compiled the order of parts as shown in the Control Byte is from most to significant bit to least: S, X, A, T, Y, B, P, Q. The lower bass clef, where used, is played by the pedals and can contain two parts, tails up (P) and down (Q).

Compiling & Editing The Data

Visual Basic and Windows can now be closed and a compilation program loaded in GWBASIC under MS-DOS. Details of the file-stem (Bday), bar numbers (1, 5) and Folder (Happy) are entered, together with an estimate of the required metronome value in crotchet beats per minute. The compiler then reads each if the .DAT files in turn and processes them into the format required by the BBC program. The complete data list is saved as a .BIN file, e.g. 8HBDAY1.BIN , indicating 8 parts (and 7+ext file name).

[Left - raw data Editor on the PC - click image for bigger version]

Control is now passed to a second program in GWBASIC. This enables the data to be edited and any errors and omissions corrected. In this 8-part PC editor two lines of data, comprising 32 columns or events, can be displayed. Note that a line of displayed data does not as a rule correspond to a line of the printed music.

Various features of the data are indicated by their colours: green (decimal) numerals indicate memory addresses at which the data for each event begins. Red (decimal) numerals are the Duration Parameters. Pale blue (hexadecimal) numbers are the Control Bytes, and the white characters define the note letters and the octaves in which they are situated. The usual range of organ music is from two octaves below middle C (C1-B1, and C2-B2) to two and a half or three octaves above (C3-B3, C4-B4a and C5-F5 in this case).

Pressing any key at this stage of the display causes the lower line of 16 columns to be erased and replaced by cues and space for input statements to make any changes [right - click image for bigger version].

Phrasing in organ music is achieved solely by small adjustments to the duration of selected chords and by short gaps inserted between them. The data as initially compiled will often sound rather bland and boring but can be made to sound more realistic by careful editing at this stage. In particular it is the custom to increase the length  of the first note in each bar by one unit, a process carried out automatically by the compiler.

Transferring The Data

[Left: the equivalent Editor on BBC Micro - click image for bigger version]

After the data has been edited it is wise to save it to a different filename, e.g. 8HBDAY2.BIN

A further GWBASIC program is then invoked to transfer the file over a parallel cable to a BBC where it is received and saved by another program. There is also a BBC data editing program but due to memory space constraints it is very limited in scope compared to the PC version & can display only 10 cols or events at a time. The data, now on a lovely old BBC floppy disc, can be taken to the church to be tested on the organ. If necessary, final adjustments can be made there using the BBC editor.

So Why Bother?

In typical geek fashion, the project was originally undertaken to test an idea and see if it could be done. After a few teething troubles were ironed out it has proved extremely versatile and reliable and appears to be capable of playing almost any organ music that can be rendered on a single-manual instrument. It just requires sufficient time and patience in setting up and editing the data.

It now plays most of the voluntaries in the weekly service and has even been used for an evening’s organ recital, raising money for charity. With the aid of a computer-literate assistant, it has occasionally been used to accompany the hymn singing when no organist (Dad) has been available. However, setting up the files for 5 hymns is no trivial task since each verse may need to be differently edited for correct phrasing due to different words.

Ernie Performs!

And now for a short recital… (use http://cazm.eu/ernie3u as a shortcut):

Afterthought

I have often wondered if, instead of spending so much time designing hardware, software and inputting data to the system, Dad had spent the time practicing the organ tunes in the first place, he would be able to play them himself! But that would not have been half the fun!

Further Reading

For more details, see Part 1 (Intro) and Part 2 (Machine Control).

The Switching Circuit in Parallel

[Right: Transistor Switching for each Note - click image for bigger version]

The analogue switching circuit for each note looks like this:

A 1-bit data latch stores the value of each note, ON or OFF.

The LEDs were originally provided to facilitate trouble-shooting at the development stage, but now provide entertainment for interested spectators! It will be noted that the components are grouped to correspond to the layout of keys on the keyboard:

A Quick Demontration!

Here is a short video showing the switching boards whilst the organ plays a familiar tune… (use http://cazm.eu/ernie2u as a shortcut):

Addressing The Latches

[Left: Buffers Latches for 1 Note - click image for bigger version]

The diagram of a sample latching circuit is shown below – there are 4 latches per chip, but there are only two clock lines, each one clocking two latches.

So each latching operation requires two bits distributed via a network of 74LS04 inverting buffers to provide the necessary fan-out.

[Right: Part of CLK Routing Circuit - click image for bigger version]

A single 1-0-1 clock pulse is then routed to one latch pair only, using a 2-to-4 74LS139 decoder and a series of 1-to-16 74L154 demux chips, as shown. This arrangement requires 5 address bits as well as the two data bits and one clock bit.

Each of the 32 5-bit addresses points to a pair of latches, so giving access to a maximum of 64 individual latches. There are only 54 notes on the manual organ, but some of the spare latches are used for  auxiliary functions, including the operation of the master switching transistors in th 14V supply to upper and lower halves of the analogue switching board.

Opto-Isolators, Decoders and Buffers

[Far Left: Opto isolators Decoders and Buffers of the  address routing circuit board]

[Left: Latches and Buffers of the latch circuit]

Much of the above hardware is duplicated to provide independent operation of the 30-note pedal organ, but this needs only one additional address line to distinguish between the two sections.

Thus:
Note address bits – PB0-4
Manual/Pedal select – PB5
Data output bits – PB6-7

Machine Control

Operation of the above hardware is controlled by a machine code program running on the BBC Micro. A user interface in BBC BASIC, normally running in MODE 6, controls the display, selection and loading of items from the music menu. Prior to the transfer of control to the machine code there is provision for setting a number of playing parameters, whose values are passed via the Resident Integer Variables.

Further Reading

For more details, see Part 1 (Intro) and Part 3 (Generating The Data).

I thought a bunch of BarCamping geeks would appreciate knowing about this madcap scheme, so I put together this presentation and ran sessions at BarCamp Blackpool and BarCamp London 7. I hope you enjoy.

About The Project Engineer

I am presenting a hardware hack project which has been undertaken by my dad, Geoff King [left]. He is a closet geek/engineer/tinkerer with many years’ experience under his belt.

He spent most of his career before retirement in the Physics Department of the University of Essex where he taught the students how to interface lab experiments with KIMs, then BBCs, and later PCs.

When the BBC Model B arrived, he had an idea to use one to play the organ in his local church, where he has been organist since the mid-1960’s.

But in the early 1980’s they were expensive state-of-the-art machines – as you may have seen recently on the excellent BBC4 series Electric Dreams!

So the idea was put on hold for a while. But you know a geek. An idea never really goes away… Some 20 years later, with his retirement looming, he was able to “acquire” several Beebs, by then regarded as redundant and heading for the scrap heap. The idea was dusted down, and Ernie the Electronic Organist was born.

The Organ

The church organ is a modest affair of 6 speaking stops on a single 54-note manual keyboard, with a single stop on an independent 30-note pedal organ.

[Right - the organ sits in a corner of the church]

As small organs go, the instrument is unusual in having electro-pneumatic action.

This is in contrast to the traditional system of rods and levers, known as trackers, linking the keyboard to the pallet valves which supply air to the pipes.

Switches beneath the keys supply current to a series of solenoids which operate small valves controlling the air supply to the pneumatic motors attached to the pallet valves.

[Left - the organ console with pedals below, and the BBC Micro mounted on the wall next to the seat]

Hardware In Action

This video shows a part of the wind chest and the solenoids in action whilst the organ is played (use http://cazm.eu/ernie1u as a shortcut):

Electro-Pneumatic Action

[Left, Electric action for each note - click image for bigger version]

An unregulated PSU provides up to 10 amps of current at a nominal 14 volts DC to power the action.

One side of each magnet is connected to the 0 volt rail, with the keyboard switches on the +14 volt side.

The aim of the project is to simulate a series of computer-controlled switches in parallel with the keyboard switches.

Further Reading

For more details, see Part 2 (Machine Control) and Part 3 (Generating The Data).

I’m really looking forward to attending the upcoming Unsheffield event which kicks off next Friday evening. It is brought to you by the same team that organised BarCampSheffieldII last year, but they felt that they wanted to deviate a little from the standard BarCamp format, hence the rebranding of this new event.

I will endeavour to write more about the event during or shortly afterwards.

• Plug & Play:
  Drop in a widget, little or no JavaScript knowledge required, just customise some options and go – no flexibility
• Some assembly required:
  Write common utilities, use pre-made code to distance yourself from browser bugs – flexible, until you hit a browser bug
• Down and dirty:
  Write all code from scratch, deal directly with bugs, quirksmode can save your life – eccessively flexible – almost too flexible
• Use JavaScript library:
  Makes JavaScript bearable, gets the job done fast, simplifies cross-browser support – easily customisable

John then did a comparison between the various JavaScript libraries, including jQuery, Prototype, YUI and Dojo, which are commonly in use. A developer survey showed that jQuery and Prototype were used by around 32% of developers; YUI was 22% and others around 14%.

John’s full slides give much more detail of each library’s strengths.

John’s presentation: slides (slideshare) | audio (mp3)

Nate Koechley

Nate began by giving us a bit of historical context to the way Yahoo! has evolved over the years.

He then covered topics such as Yahoo’s server architecture, graded browser support [see below], progressive enhancement, unobtrusive JavaScript etc.

He suggests we all have an interesting set of decisions to make regarding front-end design:

1. Do what is standard
   if impossible, then
2. Do what is common
   if impossible, then
3. Do what it takes

Then we get on to:

1. Do what is simple
   +
2. Do what is flexible & progressive
   +
3. Do what is open

This is in order to satisfy the multiple audiences for any website: Users, Developers, Machines.

At Yahoo!, they focus on 8 specific areas:

1. HTML
2. CSS
3. JavaScript
4. Accessibility
5. Internationalisation
6. Performance
7. Infrastructre & Process
8. Tooling

They use tools such as JSLint to check code for quality, and adopt the idioms it promotes to improve their code. Also, unit testing with YUI Test.

There’s much more detail in his slides (see below).

Nate’s presentation: slides (blog/slideshare) | audio (mp3)

James Graham / Lachlan Hunt

What can you do with it now, what in the future?

Intro
Next iteration of HTML spec. Long overdue for overhaul. What are we trying to achieve? Do things you can’t do now without JS, for instance. Working on HTML and XHTML together. Authors can choose which is most appropriate for them.

Design Principles

• Compatability – Browsers must remain compatible with existing content, old sites MUST still work.
• Degrade gracefully – make new features work in, or at least not break, new browsers.
• Don’t reinvent the wheel - fix what we already have, don’t reinvent it from scratch.
• Pave the cowpath – consider Use Cases – look what authors already do and improve where neccessary.c.f. Microformat Date/Time pattern.
• Evolution, not revolution - make incremental improvements. Can’t discard existing content and start fresh.
• Solve real problems – ensure work is relevent to web developers. Identify the problems first, then find solutions.
• Priority of Constituencies - have to prioritise the needs of:
  Users, authors, implementers, spec writers, theoretical purity
• Secure by design – protect end users from malicious intent
• Separation of Concerns – Separate presentation, structure, semantics where doing so provides real benefits. <b> and <i> are still in the spec.
• DOM Consistency – minimize differences between HTML and XHTML, allow scripts to work now.
• Avoid needless complexity – authors won’t use something complex if they don’t understand it
• Well-defined Behaviour – 97% of web has syntax errors! Define precisely what browers must do with all possibly bad input.
• Handle Errors – authors make mistakes all the time, the spec must define how browsers handle the errors.
• Media independence – make sure pages work on different media, devices and platforms.
• Support World Languages – support pages in any language, bi-directional text etc
• Accessibility - provide for the needs of users with disabilities. Built-in preferred over add-on accessibility, where possible.

When can we start using HTML5?
As soon as the browsers start implementing the features. FF3, IE8 support some of the spec.

What can I do with it?
Common elements of a blog – header, main nav, article, sidebar, footer. So we get:

<header> element – for site-wide header, not H1. Title/subtitle etc.
<nav> element – screenreaders could jump straight to it easily
<article> element – for the main body
<aside> element – for sidebar etc, pullquotes.
<footer> element – for copyright info

These can add more consistency than using <div>s and variable class names.

<section> elements can be nested – each of which has H1 – without worrying about correct nesting of H1, H2 elements.

<time> – for posted date of blog item. Attribute has machine-readable timestamp, tag wraps human-readable content.
<figure> – represents image(or table etc)+caption, <legend> nested inside to associate it together.
<caption> not used for reasons of backwards compatibility.
<meter> – attributes shows rating of content – the bar is drawn by the browser not meant as a graphic. Eg, content of element is 3/5, the bar is drawn by the user agent. Also progress bars
<progress> for dynamic (ajax) apps.
<video> – native video support in browsers, DOM APIs for providing custom interfaces, no more dependance on Flash. Browser provides the controls etc. Casual authors can quickly cope with video files.
<canvas> – dynamically draw graphics and text, graphics-oriented DOM APIs.

Offline Web Apps – offline caching APIs, local storage, SQL database.
Developer Tools – HTML5 conformance checker – exceeds the capabilities of traditional DTD bases validators. Gives more useful info.
Parsing HTML5 – libraries for python, ruby. off-the-shelf parser reduces reliance on RegExpr hacks.
The Community – diverse group of individuals and organisations. W3C, WHATWG trying to work together. Open to everyone.
How to Contribute – general feedback, develop tools, research, community participation.

• blog.whatwg.org
• forums.whatwg.org
• wiki.whatwg.org
• Mailing list and IRC.

• My photographic blog
• My rubgymad blog
• My web design blog
• Stuff I post to Flickr
• My tweets from Twitter
• Stuff I’m reading via del.icio.us

I decided against using my Last.fm feed for the moment, as it would probably swamp all the other inputs (I listen to a lot of music while working, it’s one of the perks of working from home, no-one moans about your choice of songs!).

Having got the basic lifestream out of Pipes, I used Dreamweaver’s XSLT transform functionality to generate a list which would sit in my ASP.NET page. I wanted to use specific icons to show which feed each item was from. Cristiano was using a JSON output for his pipe, but mine is coming out as RSS, so the custom ID’s applied in the pipe weren’t getting through, since they’re not part of the RSS spec.

CSS3 attribute selectors are one option, but they don’t work in clunky browsers like IE6. So having also been at Simon Willison’s jQuery session at BarCampLondon3, I thought I’d have a play with with the library to see if I could do some neat DOM manipulation to add the correct class to each list item.

The Llifestream list is marked up thus: <ul id=”lifestream”>. I added some jQuery to insert the class for the list element, based on the attribute of the link it contains. That requires a parent element to be changed, based on it’s child’s attributes. Slightly tricky for a jQuery novice like myself. It took me a while but eventually I found the correct syntax:

$(document).ready(function() {
$(“#lifestream > li > a[@href^=http://twitter]“).parent(“li”).addClass(“twitter”);
});

The first line calls jQuery once the full DOM is loaded; line 2 (which looks rather horrible with text wrap, but bear with me) selects an anchor with the attribute which begins with “http://twitter”, but I wanted the class added to the parent LI, so hence the chaining of jQuery functions.

Now all I needed to do was to add a case for each link type to my new lifestreamclasses.js file and add a linke to it in the header of my lifestream page, and the proper stylings can be applied. I decided to keep them in a separate JS file for ease of maintenance. Once the pipe has mashed it all together and I’ve written the relevant styles into the stylesheet, the resulting RSS aggregated feed looks like this.

Now I’m beginning to get to grips with PHP/mySQL for development. That’s going well too. And having used mySQL for a while, I can see the advantages over Access. But what I’d really like to do is upsize a few of my Access databases to mySQL and have them connect to my existing .NET applications, without having to re-write the damned things.

The data migration tools available to s smooth job, and the data is sitting there, ready to go. But now I’ve hit a brick wall. How to tell Dreamweaver I want to use a mySQL database instead of access! So I began looking for the correct connection string, this was some help. I also downloaded MySQL ODBC 3.51 and installed it.

Then I set the web.config file entry to this (bold being the connection string given in the link above):

<add key=”MM_CONNECTION_STRING_connPortfolio” value=”Driver={MySQL ODBC 3.51 Driver};Server=localhost;Database=myDatabase;User=myUser;
Password=myPassword;Option=3;” />

I tried the TEST button and Dreamweaver connected successfully! But try running the site via the browser (or Dreamweaver Live Data View) and it falls over with an error:

System.ArgumentException: An OLE DB Provider was not specified in the ConnectionString. An example would be, ‘Provider=SQLOLEDB;’.
at System.Data.OleDb.OleDbConnectionString.ValidateParse()

So tried a different connection method, using Connector/Net 1.0.9 with this syntax in the web.config file – but got very similar results. Then I found this following in an Adobe Tech Note (my emphasis):

Do I have to use ODBC?
No. For ASP sites you can also connect to a database using OLEDB. For ASP.NET sites you must use OLEDB or the native ASP.NET SQL Server connector.

So it looks like it has to be OLEDB, but how to put the correct provider in the connection string? Nothing I’ve tried seems to work! Any clues? Has anybody actually got this combination to work?

• Dreamweaver 8
• ASP.NET/C# server model
• mySQL database

[Mobile Web Best Practices cue cards]
So for those who don’t have a copy, I thought I would share the wisdom that they detail. More info can be found at http://www.w3.org/TR/mobile-bp/ – but the below is a distilled and much more user-friendly summary.

10 Ways To Mobilise
The cards are broken into ten topics, with hints and advice on each:

1. Design for One Web
Content designed with diverse devices in mind reduces cost, increases flexibility, and reaches the needs of more people.

Thematic constistency – ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices.

Capabilities – exploit device capabilities to provide an enhanced user experience.

Deficiencies – take reasonable steps to work around deficient implementations.

Testing – carry out testing on actual devices as well as emulators.

2. Rely on Web Standards
In the highly fragmented market of devices and browsers, standards are the best guarantee for interoperability.

Validate Markup – create documents that validate to published formal grammars.

Content Format Support – send content in a format that is known to be supported by the device.

Content Format Preferred – where possible, send content in a preferred format.

Character Encoding Support – ensure that content is encoded using a character encoding that is known to be supported by the target device.

Character Encoding Use – indicate in the response the character encoding being used.

Style Sheet Use – use style sheets to control layout and presentation, unless the device is known not to support them.

Structure – use features of the markup language to indicate logical document structure.

Error Messages – provide informative error messages and a means of navigating away from an error message back to useful information.

3. Stay away from known hazards
Thoughtful design can help reduce usability problems due to small screens and keyboards, and other features of mobile devices.

Pop Ups - do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

Tables Nested – do not use nested tables.

Tables Layout – do not use tables for layout.

Graphics For Spacing – do not use graphics for spacing.

No Frames - do not use frames.

Image Maps – do not use image maps unless you know the device supports them effectively.

4. Be cautious of device limitations
When choosing to use a particular web technology, consider that mobile devices vary greatly in capability.

Cookies – do not rely on cookies being available.

Objects or Script – do not rely on embedded objects or script.

Tables Support – do not use tables unless the device is known to support them.

Tables Alternatives – where possible, use an alternative to tabular presentation.

Style Sheets Support – Organise documents so that, if necessary, they may be read without style sheets.

Fonts – do not rely on support of font related styling.

Use of Colours – Ensure that information conveyed with colour is also available without colour.

5. Optimize navigation
Simple navigation and typing become critical when using a small screen and keyboard, and limited bandwidth.

Navbar – provide only minimal navigation at the top of the page.

Navigation – provide consistent navigation mechanisms.

Link Target ID – cleary identify the target of each link.

Link Target Format – Note the target file’s format unless you know the device supports it.

Access Keys – assign access keys to links in navigational menus and frequently accessed functionality.

URIs – keep the URIs of site entry points short.

Balance – take into account the trade-off between having too many links on a page and asking the user to follow too many links to reach what they are looking for.

6. Check graphics & colours
Images, colours and style brighten content, but require care due to inconsistent support for some formats low-contrast screens.

Images Resizing – resize images at the server, if they have an intrinsic size.

Large Graphics – do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical information would otherwise be lost.

Images Specify Size – specify the size of images in markup, if they have an intrinsic size.

No Text Alternative – provide a text equivalent for every non-text element.

Colour Contrast – ensure that foreground and background colour combinations provide sufficient contrast.

Background Image Readability – when using background images, make sure that content remains readable on the device.

Measures – do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values.

7. Keep it small
Smaller sites make us
ers happier by costing less in time and money.

Minimise – use terse, efficient markup.

Page Size Limit – ensure that the overall size of page is appropriate to the memory limitations of the device.

Style Sheet Size – keep style sheets small.

Scrolling – limit scrolling to one direction, unless secondary scrolling cannot be avoided.

8. Use the network sparingly
Web protocol features can help improve the user experience by reducing the impact of network bottlenecks and latencies.

Auto refresh - do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it.

Redirection - do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes.

External Resources - keep the number of externally linked resources to a minimum.

Caching – provide caching information in HTTP responses.

9. Help & guide user input
Keyboards and other input methods on mobile devices can be tedious to use, so effective designs minimize the need for them.

Minimise Keystrokes – keept the number of keystrokes to a minimum.

Avoid Free Text – avoid free text entry in forms, where possible.

Provide Defaults – provide pre-selected default values where possible.

Default Input Mode – Specify a default text entry mode, language and/or input format, if the target device is known to support it.

Tab Order – Create a logical order through links, form controls and objects.

Control Labelling – label all form controls appropriately and explicitly associate labels with form controls.

Control Position – position labels so they lay out properly in relation to the form control to which they refer.

10. Think of users on the go
Web users on the go want compact information when time is short and distractions many.

Page Title – provide a short but descriptive page title for every page.

Clarity – use clear and simple language.

Central Meaning – ensure that material that is central to the meaning of the page precedes material that is not.

Limited – limit content to what the user has requested.

Suitable – ensure that content is suitable for use in a mobile context.

Page Size Usable – devide pages into usable but limited size portions.

And reading through these, most of the list sounds equally applicable to overcome other accessibility issues. Wise advice, which isn’t always easy to follow!