7 replies [Last post]
Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 9 years 18 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

After reading Lorraine's excellent thread on accessibility I decided to put a page through the paces to try to get a better understanding of the changes required for dynamic page generation.

test page
[url=http://wiki.jalakai.co.uk/include/preg.php?subject=the%20cat%20sat%20on%20the%20mat%20to%20eat%20a%20rat&replace=&pattern=~%28.%29%28at%28.%29%29~&replace=-$2$3$1-&do%5bmatch_all%5d=match_all]same test page with data and results[/url]

Ok, its quite a simple page and taking into account Lorraine's emphasis on common sense I did what I could to meet the points raised in all the different checklists.

I would appreciate some comments on the pages accessibility and some thoughts on the following:

All of the automated page testers picked up on the page not having explicit labels for input elements. Is it reasonable (especially for those using screen readers) to nest the form element within a label tag or is the for attribute required for the page to make sense?

e.g.,
<div><label for='subject'><span class='accesskey'>s</span>ubject</label><input id='subject' ... /></div> rather than my current markup.


They also picked me up for using fieldsets without legends. In this simple form its not a big issue, but am I being lazy by using fieldsets in the form where they are really fulfilling no other function but layout (in this instance they don't even add to the page when its rendered without any styles)?(1)

I recall along time ago giving up on using the <button> tag because of the failings of IE (I can't recall exactly what the issue was). Without being able to style submit button text is there any way to convey the access key for that button?

All answers greatly appreciated,

Chris


(1) i think in formulating that question I have answered it Smile

rguy84
Offline
Enthusiast
Seattle, Wa
Last seen: 15 years 13 weeks ago
Seattle, Wa
Timezone: GMT-7
Joined: 2004-07-18
Posts: 60
Points: 0

Accessibility exercise

The pages get a thumbs up from me. I don't think you need to include the label in there. I believe a screen reader reads it fine when you have the name="" on the form. I don't have JAWS (one of the most used screen readers) on the computer I am using now, so I can't confirm this.

Ryan
my blog

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 15 years 23 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

Accessibility exercise

Chris
I'm not even going to pretend I know what the h3ll your page is talking about :roll:
But I the test page through WebbIE and this it what a standard screen-reader user would hear read out:

Quote:
Webpage: Regular Expression Testing - for php's preg functions
Page Headline: RegEx Assistant
Test regular expressions against php's preg functions.
The data you enter will be passed directly to the preg function indicated by the button pressed.
The pattern must be enclosed by matching delimiters. It can be followed by any number of perl or php trailing options with the exception of the 'e' flag.
For more information on perl compatible regular expressions in php, refer to the
Link 1: php manual .
s ubject (1)
Text input area 1: subject (2)
p attern (1)
Text input box 1: /pattern/ (2)
r eplace (1)
Text input box 2: replace (2)
Submit button 1: (clear) (3)
Submit button 2: (match)
Submit button 3: (match all)
Submit button 4: (split)
Submit button 5: (replace)
©2005 Jalakai Insites

I'll just pick up on 3 specific accessibility thangs.

(1) Access keys are on their way out, but, if you are going to use them, the code should contain acccesskey="s" or whatever. The span idea which I assume is to underline the first letter of s ubject etc, is merely visual but would read as "s (pause) ubject" etc

(2) "Label for" would link the three input titles to the err... input area specifically relating to each. In a real world example, I assume the actual input would be filled in live-time. If so you should use input type as in this simple search thingy
<input type="text" title="type your search term here" size="30" id="standardsearch" />
Your example is the way to go, with the exception of the bits of code caught up under (1) above.

(3) Assume the user has completed the input boxes and then moves onto the evaluation expressions. It seems more logical to me to place the "Clear" box after Replace, rather than offer Clear as the first option. OK for those who can see all of them, but if you hear Clear first, that could be confusing.

Yeah, forget fieldset in these circumstances. It's not "right" to leave it out, but I can't see how it is going to aid further comprehension either because the whole test page is the fieldset.

Here's what the emulator makes of the results on the second page.

Quote:

results: preg_match_all(pattern, subject, match)
returned
4
match
match[0]
match[0][0]
cat
match[0][1]
sat
match[0][2]
mat
match[0][3]
eat
match[1]
match[1][0]
c
match[1][1]
s
match[1][2]
m
match[1][3]
e
match[2]
match[2][0]
at
match[2][1]
at
match[2][2]
at
match[2][3]
at
match[3]
match[3][0]
match[3][1]
match[3][2]
match[3][3]
©2005 Jalakai Insites

I'll leave it to you to decide what your "listener" would make of all those match bits at the bottom. Ask your significant other to close their eyes and read them out to her/him.

Is this the sort of thing you were after?

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 15 years 23 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

Accessibility exercise

Another point on that clear thing - forgot to test, sorry.
You can see but you can't use a mouse, you would get around the page using the tab key.
Tab into the screen, the cursor alights to the right of subject in the input area and the Clear box appears to have focus. How are you going to get to the Clear box?

So you laboriously fill out the subject, then pattern then replace. Then select Clear - shucks I only wanted to change the pattern, now I've got to start all over again Sad

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 9 years 18 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

Accessibility exercise

Thanks to both of you - I have updated the page in the light of your comments.

Yes, Lorraine, thats what I was after.

- very good point about the clear button.

- the accesskey attribute is present for each input field and button. I was conscious that there isn't much point specifying an accesskey if there is no way to alert the user to it. Dropping them altogether isn't a problem. For now I will drop the span and move something into the title text. Its odd that a screen reader should pause after a span when there is no white space. A span should be a contextless element. I guess its one of those things that sometimes you want it one way, sometimes another.

- the results pretty well have to be that way. Its a list of what the functions themselves output, anything else wouldn't be a true reflection and would defeat the purpose of the page. That isn't to say the information couldn't be organised differently Smile.

Thanks again,

Chris

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 15 years 23 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

Accessibility exercise

At last, I've found my reference bits, haven't used them for some time (note to self must re-arrange bookmark structure or get around to that database thingy)
So, for what they may be worth, now..... :roll:
http://www.jimthatcher.com/webcourse8.htm
http://www.websemantics.co.uk/tutorials/accessible_forms/
http://www.websemantics.co.uk/tutorials/accessible_forms/

At least you should be able to get a better handle on why to use "label for", particularly on complex forms, with a number of input fields.

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 9 years 18 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

Accessibility exercise

Those last two links are the same Wink

I got the label thing - but figured implicit association was satisfactory, where the input element is nested within the label element. There seems some confusion at webSemantics.

Quote:
2. Input fields require implicit descriptions [A]. Text description must precede input (except radio and checkbox types) and be wrapped in a label. ...

3. Input fields require explicit descriptions [A]. The "for" attribute in the label element must be associated to the input id. ...

W3C say, use while user agents (browsers?) don't properly recognise the implicit association. So its all good and the for is in there now. Should have been there after the last post by it got missed when I did the changes. Tongue

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 15 years 23 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

Accessibility exercise

Quote:
Those last two links are the same

Told you my bookmarks were a mess Crying
Scratch one of those websemantics ( that's probably what's confusing them anyway Wink )
What I meant to put up, had I been sober at the time was:
http://www.webstandards.org/learn/tutorials/accessible-forms/01-accessible-forms.html