E-mail List Archives
Thread: Screen reader and greyed-out submit button
Number of posts in this thread: 8 (In chronological order)
From: Barry Hill
Date: Tue, Jan 14 2020 11:57PM
Subject: Screen reader and greyed-out submit button
No previous message | Next message →
Hi all
When a web form has a submit button that is greyed-out when the form is
incomplete, how should it be handled with screen readers? Or should the
user be able to submit the form and get the alert that the form is
incomplete?
Thanks in anticipation.
Cheers
Barry
From: Graham Armfield
Date: Wed, Jan 15 2020 3:58AM
Subject: Re: Screen reader and greyed-out submit button
← Previous message | Next message →
Hi Barry,
Having a submit button only become active when all fields pass the form
validation seems to be a popular pattern within some organisations. But
it's also considered a bit of an anti-pattern by some within the UX (user
experience) and accessibility communities.
I can think of a couple of reasons why this is not a good idea.
Firstly, the submit button on/off functionality relies on JavaScript
routines running in the browser to perform the validation before enabling
the submit button. Some people may be browsing in setups where JavaScript
has been blocked, or where the JavaScript files don't load and these users
may never be able to submit the form since the validation routines don't
run.
Secondly, I'm told that if field prompts are not sufficiently informative,
or don't contain format guidance, some people favour submitting a form
early and using the resultant error messages to help understand the
information that is required. If the submit button is not activated until
validation is satisfied, this is not possible.
There are also some other ideas in this article:
https://axesslab.com/disabled-buttons-suck/
Regards
Graham Armfield
coolfields.co.uk <http://www.coolfields.co.uk/>;
M:07905 590026
T: 01483 856613
@coolfields <https://twitter.com/coolfields>
On Wed, 15 Jan 2020 at 06:57, Barry Hill < = EMAIL ADDRESS REMOVED = > wrote:
> Hi all
>
>
>
> When a web form has a submit button that is greyed-out when the form is
> incomplete, how should it be handled with screen readers? Or should the
> user be able to submit the form and get the alert that the form is
> incomplete?
>
>
>
> Thanks in anticipation.
>
>
>
> Cheers
>
>
>
> Barry
>
>
>
> > > > >
From: Birkir R. Gunnarsson
Date: Wed, Jan 15 2020 6:50AM
Subject: Re: Screen reader and greyed-out submit button
← Previous message | Next message →
Lots of good points in that email!
Here are a few more thoughts.
The native HTML way to mark form controls as unavailable is the
disabled attribute
<button disabled>submit</button>
(should be "differently able" to be more PC)
This attribute removes the control from te focus order and disables
the click event on it.
I believe this is consisent across browsers.
If you want to keep the element focusable but dsabled you have to do
that with a Javascript (event.preventDefault()) and then you can
aria-disabled="true" on the element to mark it as disabled for a
screen reader.
YOu haveYou hav to use this approach for links (including links turned
into buttons with styling and ARIA) because the disabled attribute is
not valid on links.
IN TML5 you can do a lot of browser validation without Javascript, by
using the appropriate input type attributes (e.g. type="email" on an
input causes browser validtion errors if you have no @ symbol, or
multiple ones).
If you are good at regular expressions you can use the pattern
attribute to force all sorts of input validation.
These are not Javascript dependent and if the browser does not support
HTML5 they wll basically just be regular text inputs.
On 1/15/20, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Barry,
>
> Having a submit button only become active when all fields pass the form
> validation seems to be a popular pattern within some organisations. But
> it's also considered a bit of an anti-pattern by some within the UX (user
> experience) and accessibility communities.
>
> I can think of a couple of reasons why this is not a good idea.
>
> Firstly, the submit button on/off functionality relies on JavaScript
> routines running in the browser to perform the validation before enabling
> the submit button. Some people may be browsing in setups where JavaScript
> has been blocked, or where the JavaScript files don't load and these users
> may never be able to submit the form since the validation routines don't
> run.
>
> Secondly, I'm told that if field prompts are not sufficiently informative,
> or don't contain format guidance, some people favour submitting a form
> early and using the resultant error messages to help understand the
> information that is required. If the submit button is not activated until
> validation is satisfied, this is not possible.
>
> There are also some other ideas in this article:
> https://axesslab.com/disabled-buttons-suck/
>
> Regards
> Graham Armfield
>
> coolfields.co.uk <http://www.coolfields.co.uk/>;
> M:07905 590026
> T: 01483 856613
> @coolfields <https://twitter.com/coolfields>
>
>
> On Wed, 15 Jan 2020 at 06:57, Barry Hill < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi all
>>
>>
>>
>> When a web form has a submit button that is greyed-out when the form is
>> incomplete, how should it be handled with screen readers? Or should the
>> user be able to submit the form and get the alert that the form is
>> incomplete?
>>
>>
>>
>> Thanks in anticipation.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Barry
>>
>>
>>
>> >> >> >> >>
> > > > >
--
Work hard. Have fun. Make history.
From: Graham Armfield
Date: Wed, Jan 15 2020 8:42AM
Subject: Re: Screen reader and greyed-out submit button
← Previous message | Next message →
Thanks for your comments Birkir.
I would however caution against relying on the inbuilt browser validation
for input type="email", input type="number" etc. A recent survey pointed
out that the resultant error messages are not always read out by screen
readers. Also if you have multiple numeric or email fields in a form, it's
not clear to screen reader users which of the fields generated the error
message.
In my view it's best to deactivate the browser validation and rely on
purpose built validation and informative error messages - whether generated
by JavaScript or by return from a server submit.
Regards
Graham Armfield
coolfields.co.uk <http://www.coolfields.co.uk/>;
M:07905 590026
T: 01483 856613
@coolfields <https://twitter.com/coolfields>
On Wed, 15 Jan 2020 at 13:50, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> Lots of good points in that email!
> Here are a few more thoughts.
> The native HTML way to mark form controls as unavailable is the
> disabled attribute
> <button disabled>submit</button>
> (should be "differently able" to be more PC)
> This attribute removes the control from te focus order and disables
> the click event on it.
> I believe this is consisent across browsers.
> If you want to keep the element focusable but dsabled you have to do
> that with a Javascript (event.preventDefault()) and then you can
> aria-disabled="true" on the element to mark it as disabled for a
> screen reader.
> YOu haveYou hav to use this approach for links (including links turned
> into buttons with styling and ARIA) because the disabled attribute is
> not valid on links.
>
> IN TML5 you can do a lot of browser validation without Javascript, by
> using the appropriate input type attributes (e.g. type="email" on an
> input causes browser validtion errors if you have no @ symbol, or
> multiple ones).
> If you are good at regular expressions you can use the pattern
> attribute to force all sorts of input validation.
> These are not Javascript dependent and if the browser does not support
> HTML5 they wll basically just be regular text inputs.
>
>
> On 1/15/20, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi Barry,
> >
> > Having a submit button only become active when all fields pass the form
> > validation seems to be a popular pattern within some organisations. But
> > it's also considered a bit of an anti-pattern by some within the UX (user
> > experience) and accessibility communities.
> >
> > I can think of a couple of reasons why this is not a good idea.
> >
> > Firstly, the submit button on/off functionality relies on JavaScript
> > routines running in the browser to perform the validation before enabling
> > the submit button. Some people may be browsing in setups where JavaScript
> > has been blocked, or where the JavaScript files don't load and these
> users
> > may never be able to submit the form since the validation routines don't
> > run.
> >
> > Secondly, I'm told that if field prompts are not sufficiently
> informative,
> > or don't contain format guidance, some people favour submitting a form
> > early and using the resultant error messages to help understand the
> > information that is required. If the submit button is not activated until
> > validation is satisfied, this is not possible.
> >
> > There are also some other ideas in this article:
> > https://axesslab.com/disabled-buttons-suck/
> >
> > Regards
> > Graham Armfield
> >
> > coolfields.co.uk <http://www.coolfields.co.uk/>;
> > M:07905 590026
> > T: 01483 856613
> > @coolfields <https://twitter.com/coolfields>
> >
> >
> > On Wed, 15 Jan 2020 at 06:57, Barry Hill < = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Hi all
> >>
> >>
> >>
> >> When a web form has a submit button that is greyed-out when the form is
> >> incomplete, how should it be handled with screen readers? Or should the
> >> user be able to submit the form and get the alert that the form is
> >> incomplete?
> >>
> >>
> >>
> >> Thanks in anticipation.
> >>
> >>
> >>
> >> Cheers
> >>
> >>
> >>
> >> Barry
> >>
> >>
> >>
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >
From: Birkir R. Gunnarsson
Date: Wed, Jan 15 2020 9:18AM
Subject: Re: Screen reader and greyed-out submit button
← Previous message | Next message →
Graham
Good points, but the path forward is to pressure for more accessile
browser valdation, the vendors can create more accessible browser
validation messages.
Having to use Javascript to create accessible error messages is
non-trivial and if we can shift a larger portion of that work to the
browsers with viable accesibility we can hugely reduce the difficulty
of developing accessible forms.
What we do currently is to access the browser validation tree and use
Javascript to make sure error messages are persistent and properly
associated with the invalid inputs. I can create a code pen example to
demonstrate
I like progressive enhancement but I also see the opportunity to push
towards making form validation easier and less reliant on Javascript,
it would be a big win for accessibility.
On 1/15/20, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks for your comments Birkir.
>
> I would however caution against relying on the inbuilt browser validation
> for input type="email", input type="number" etc. A recent survey pointed
> out that the resultant error messages are not always read out by screen
> readers. Also if you have multiple numeric or email fields in a form, it's
> not clear to screen reader users which of the fields generated the error
> message.
>
> In my view it's best to deactivate the browser validation and rely on
> purpose built validation and informative error messages - whether generated
> by JavaScript or by return from a server submit.
>
> Regards
> Graham Armfield
>
> coolfields.co.uk <http://www.coolfields.co.uk/>;
> M:07905 590026
> T: 01483 856613
> @coolfields <https://twitter.com/coolfields>
>
>
> On Wed, 15 Jan 2020 at 13:50, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Lots of good points in that email!
>> Here are a few more thoughts.
>> The native HTML way to mark form controls as unavailable is the
>> disabled attribute
>> <button disabled>submit</button>
>> (should be "differently able" to be more PC)
>> This attribute removes the control from te focus order and disables
>> the click event on it.
>> I believe this is consisent across browsers.
>> If you want to keep the element focusable but dsabled you have to do
>> that with a Javascript (event.preventDefault()) and then you can
>> aria-disabled="true" on the element to mark it as disabled for a
>> screen reader.
>> YOu haveYou hav to use this approach for links (including links turned
>> into buttons with styling and ARIA) because the disabled attribute is
>> not valid on links.
>>
>> IN TML5 you can do a lot of browser validation without Javascript, by
>> using the appropriate input type attributes (e.g. type="email" on an
>> input causes browser validtion errors if you have no @ symbol, or
>> multiple ones).
>> If you are good at regular expressions you can use the pattern
>> attribute to force all sorts of input validation.
>> These are not Javascript dependent and if the browser does not support
>> HTML5 they wll basically just be regular text inputs.
>>
>>
>> On 1/15/20, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
>> > Hi Barry,
>> >
>> > Having a submit button only become active when all fields pass the form
>> > validation seems to be a popular pattern within some organisations. But
>> > it's also considered a bit of an anti-pattern by some within the UX
>> > (user
>> > experience) and accessibility communities.
>> >
>> > I can think of a couple of reasons why this is not a good idea.
>> >
>> > Firstly, the submit button on/off functionality relies on JavaScript
>> > routines running in the browser to perform the validation before
>> > enabling
>> > the submit button. Some people may be browsing in setups where
>> > JavaScript
>> > has been blocked, or where the JavaScript files don't load and these
>> users
>> > may never be able to submit the form since the validation routines
>> > don't
>> > run.
>> >
>> > Secondly, I'm told that if field prompts are not sufficiently
>> informative,
>> > or don't contain format guidance, some people favour submitting a form
>> > early and using the resultant error messages to help understand the
>> > information that is required. If the submit button is not activated
>> > until
>> > validation is satisfied, this is not possible.
>> >
>> > There are also some other ideas in this article:
>> > https://axesslab.com/disabled-buttons-suck/
>> >
>> > Regards
>> > Graham Armfield
>> >
>> > coolfields.co.uk <http://www.coolfields.co.uk/>;
>> > M:07905 590026
>> > T: 01483 856613
>> > @coolfields <https://twitter.com/coolfields>
>> >
>> >
>> > On Wed, 15 Jan 2020 at 06:57, Barry Hill < = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> >> Hi all
>> >>
>> >>
>> >>
>> >> When a web form has a submit button that is greyed-out when the form
>> >> is
>> >> incomplete, how should it be handled with screen readers? Or should
>> >> the
>> >> user be able to submit the form and get the alert that the form is
>> >> incomplete?
>> >>
>> >>
>> >>
>> >> Thanks in anticipation.
>> >>
>> >>
>> >>
>> >> Cheers
>> >>
>> >>
>> >>
>> >> Barry
>> >>
>> >>
>> >>
>> >> >> >> >> >> >> >> >> >>
>> > >> > >> > >> > >> >
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> >>
> > > > >
--
Work hard. Have fun. Make history.
From: Graham Armfield
Date: Wed, Jan 15 2020 9:47AM
Subject: Re: Screen reader and greyed-out submit button
← Previous message | Next message →
I agree Birkir, having the browser do the work properly would benefit many.
Do you think that's going to happen soon?
I would be interested in a codepen example of hooking into the browser
validation tree. I'm interested in how it would be possible to feed the
browser sufficient info to create meaningful error messages.
Thanks for the discussion.
Regards
Graham Armfield
coolfields.co.uk <http://www.coolfields.co.uk/>;
M:07905 590026
T: 01483 856613
@coolfields <https://twitter.com/coolfields>
On Wed, 15 Jan 2020 at 16:18, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> Graham
> Good points, but the path forward is to pressure for more accessile
> browser valdation, the vendors can create more accessible browser
> validation messages.
> Having to use Javascript to create accessible error messages is
> non-trivial and if we can shift a larger portion of that work to the
> browsers with viable accesibility we can hugely reduce the difficulty
> of developing accessible forms.
> What we do currently is to access the browser validation tree and use
> Javascript to make sure error messages are persistent and properly
> associated with the invalid inputs. I can create a code pen example to
> demonstrate
> I like progressive enhancement but I also see the opportunity to push
> towards making form validation easier and less reliant on Javascript,
> it would be a big win for accessibility.
>
> On 1/15/20, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
> > Thanks for your comments Birkir.
> >
> > I would however caution against relying on the inbuilt browser validation
> > for input type="email", input type="number" etc. A recent survey pointed
> > out that the resultant error messages are not always read out by screen
> > readers. Also if you have multiple numeric or email fields in a form,
> it's
> > not clear to screen reader users which of the fields generated the error
> > message.
> >
> > In my view it's best to deactivate the browser validation and rely on
> > purpose built validation and informative error messages - whether
> generated
> > by JavaScript or by return from a server submit.
> >
> > Regards
> > Graham Armfield
> >
> > coolfields.co.uk <http://www.coolfields.co.uk/>;
> > M:07905 590026
> > T: 01483 856613
> > @coolfields <https://twitter.com/coolfields>
> >
> >
> > On Wed, 15 Jan 2020 at 13:50, Birkir R. Gunnarsson <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Lots of good points in that email!
> >> Here are a few more thoughts.
> >> The native HTML way to mark form controls as unavailable is the
> >> disabled attribute
> >> <button disabled>submit</button>
> >> (should be "differently able" to be more PC)
> >> This attribute removes the control from te focus order and disables
> >> the click event on it.
> >> I believe this is consisent across browsers.
> >> If you want to keep the element focusable but dsabled you have to do
> >> that with a Javascript (event.preventDefault()) and then you can
> >> aria-disabled="true" on the element to mark it as disabled for a
> >> screen reader.
> >> YOu haveYou hav to use this approach for links (including links turned
> >> into buttons with styling and ARIA) because the disabled attribute is
> >> not valid on links.
> >>
> >> IN TML5 you can do a lot of browser validation without Javascript, by
> >> using the appropriate input type attributes (e.g. type="email" on an
> >> input causes browser validtion errors if you have no @ symbol, or
> >> multiple ones).
> >> If you are good at regular expressions you can use the pattern
> >> attribute to force all sorts of input validation.
> >> These are not Javascript dependent and if the browser does not support
> >> HTML5 they wll basically just be regular text inputs.
> >>
> >>
> >> On 1/15/20, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
> >> > Hi Barry,
> >> >
> >> > Having a submit button only become active when all fields pass the
> form
> >> > validation seems to be a popular pattern within some organisations.
> But
> >> > it's also considered a bit of an anti-pattern by some within the UX
> >> > (user
> >> > experience) and accessibility communities.
> >> >
> >> > I can think of a couple of reasons why this is not a good idea.
> >> >
> >> > Firstly, the submit button on/off functionality relies on JavaScript
> >> > routines running in the browser to perform the validation before
> >> > enabling
> >> > the submit button. Some people may be browsing in setups where
> >> > JavaScript
> >> > has been blocked, or where the JavaScript files don't load and these
> >> users
> >> > may never be able to submit the form since the validation routines
> >> > don't
> >> > run.
> >> >
> >> > Secondly, I'm told that if field prompts are not sufficiently
> >> informative,
> >> > or don't contain format guidance, some people favour submitting a form
> >> > early and using the resultant error messages to help understand the
> >> > information that is required. If the submit button is not activated
> >> > until
> >> > validation is satisfied, this is not possible.
> >> >
> >> > There are also some other ideas in this article:
> >> > https://axesslab.com/disabled-buttons-suck/
> >> >
> >> > Regards
> >> > Graham Armfield
> >> >
> >> > coolfields.co.uk <http://www.coolfields.co.uk/>;
> >> > M:07905 590026
> >> > T: 01483 856613
> >> > @coolfields <https://twitter.com/coolfields>
> >> >
> >> >
> >> > On Wed, 15 Jan 2020 at 06:57, Barry Hill < = EMAIL ADDRESS REMOVED = > wrote:
> >> >
> >> >> Hi all
> >> >>
> >> >>
> >> >>
> >> >> When a web form has a submit button that is greyed-out when the form
> >> >> is
> >> >> incomplete, how should it be handled with screen readers? Or should
> >> >> the
> >> >> user be able to submit the form and get the alert that the form is
> >> >> incomplete?
> >> >>
> >> >>
> >> >>
> >> >> Thanks in anticipation.
> >> >>
> >> >>
> >> >>
> >> >> Cheers
> >> >>
> >> >>
> >> >>
> >> >> Barry
> >> >>
> >> >>
> >> >>
> >> >> > >> >> > >> >> > >> >> > >> >>
> >> > > >> > > >> > > >> > > >> >
> >>
> >>
> >> --
> >> Work hard. Have fun. Make history.
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >
From: Murphy, Sean
Date: Wed, Jan 15 2020 3:11PM
Subject: Re: Screen reader and greyed-out submit button
← Previous message | Next message →
I like this idea in deed. As much heavy lifting off the vendor on the browser the better in the area of accessibility the better. Assuming the browser vendor does it right in the first place which is always the risk.
Sean
From: Jeffrey (JDS)
Date: Wed, Jan 15 2020 10:53PM
Subject: Re: Screen reader and greyed-out submit button
← Previous message | No next message
Graham you are kind of talking about the The balance between today and tomorrow.
We'd be better to try and lobby browser makers and AT makers to fix this issue rather than to create work arounds.
While still needing to rely on those workarounds today.
But When it's native it's got a better chance of being used by other types of AT also.
On 1/15/20, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks for your comments Birkir.
>
> I would however caution against relying on the inbuilt browser
> validation for input type="email", input type="number" etc. A recent
> survey pointed out that the resultant error messages are not always
> read out by screen readers. Also if you have multiple numeric or email
> fields in a form, it's not clear to screen reader users which of the
> fields generated the error message.
>
> In my view it's best to deactivate the browser validation and rely on
> purpose built validation and informative error messages - whether
> generated by JavaScript or by return from a server submit.
>
> Regards
> Graham Armfield
>
> coolfields.co.uk <http://www.coolfields.co.uk/>;
> M:07905 590026
> T: 01483 856613
> @coolfields <https://twitter.com/coolfields>
>
>
> On Wed, 15 Jan 2020 at 13:50, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Lots of good points in that email!
>> Here are a few more thoughts.
>> The native HTML way to mark form controls as unavailable is the
>> disabled attribute <button disabled>submit</button> (should be
>> "differently able" to be more PC) This attribute removes the control
>> from te focus order and disables the click event on it.
>> I believe this is consisent across browsers.
>> If you want to keep the element focusable but dsabled you have to do
>> that with a Javascript (event.preventDefault()) and then you can
>> aria-disabled="true" on the element to mark it as disabled for a
>> screen reader.
>> YOu haveYou hav to use this approach for links (including links
>> turned into buttons with styling and ARIA) because the disabled
>> attribute is not valid on links.
>>
>> IN TML5 you can do a lot of browser validation without Javascript, by
>> using the appropriate input type attributes (e.g. type="email" on an
>> input causes browser validtion errors if you have no @ symbol, or
>> multiple ones).
>> If you are good at regular expressions you can use the pattern
>> attribute to force all sorts of input validation.
>> These are not Javascript dependent and if the browser does not
>> support
>> HTML5 they wll basically just be regular text inputs.
>>
>>
>> On 1/15/20, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
>> > Hi Barry,
>> >
>> > Having a submit button only become active when all fields pass the
>> > form validation seems to be a popular pattern within some
>> > organisations. But it's also considered a bit of an anti-pattern by
>> > some within the UX (user
>> > experience) and accessibility communities.
>> >
>> > I can think of a couple of reasons why this is not a good idea.
>> >
>> > Firstly, the submit button on/off functionality relies on
>> > JavaScript routines running in the browser to perform the
>> > validation before enabling the submit button. Some people may be
>> > browsing in setups where JavaScript has been blocked, or where the
>> > JavaScript files don't load and these
>> users
>> > may never be able to submit the form since the validation routines
>> > don't run.
>> >
>> > Secondly, I'm told that if field prompts are not sufficiently
>> informative,
>> > or don't contain format guidance, some people favour submitting a
>> > form early and using the resultant error messages to help
>> > understand the information that is required. If the submit button
>> > is not activated until validation is satisfied, this is not
>> > possible.
>> >
>> > There are also some other ideas in this article:
>> > https://axesslab.com/disabled-buttons-suck/
>> >
>> > Regards
>> > Graham Armfield
>> >
>> > coolfields.co.uk <http://www.coolfields.co.uk/>;
>> > M:07905 590026
>> > T: 01483 856613
>> > @coolfields <https://twitter.com/coolfields>
>> >
>> >
>> > On Wed, 15 Jan 2020 at 06:57, Barry Hill < = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> >> Hi all
>> >>
>> >>
>> >>
>> >> When a web form has a submit button that is greyed-out when the
>> >> form is incomplete, how should it be handled with screen readers?
>> >> Or should the user be able to submit the form and get the alert
>> >> that the form is incomplete?
>> >>
>> >>
>> >>
>> >> Thanks in anticipation.
>> >>
>> >>
>> >>
>> >> Cheers
>> >>
>> >>
>> >>
>> >> Barry
>> >>
>> >>
>> >>
>> >> >> >> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >>
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> >
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.