www.woking.gov.uk
Home / Site Critiques / www.woking.gov.uk
| Wing Chun wrote: |
| the council guys really need to learn the value of simplicity. |
Gosh, that's harsh.
The navigation is adapted from the Local Government Navigation List, which also has 11 top-level elements (we replaced Health and social care with About Woking to better reflect the actual information available on the site -- health and social care being services offered by the County Council).
The navigation fits in its entirety on a 1024x768 screen (assuming a maximised window and a dearth of toolbars).
James is, of course, absolutely right that only usability testing would determine whether or not there's a real problem here.
Cheers,
Andrew.
_________________
Andrew Green
Article Seven / Buy Our Honeymoon / Elements or Lower
Share: 
I've often found that a good way to test a site is to have a specific task in mind and see how easy it is to carry it out.
So, I searched the home page and heard the following:
Do it online
Apply for it [Event.]
Comment on it [Event.]
Pay for it [Event.]
Report it [Event.]
So .... 'Report it' it is .......
Having selected that link I was taken to a page that started with the usual skip-link: Skip to main content [Event.]
I selected that link, and I hear:
Report it
Although we do our best to tackle issues within the Borough as they arise, we are sometimes unaware of when or where a problem has occurred. This section gives you the chance to tell us about things that you have noticed which require our attention.
and so it goes on, giving me a number of options until I hear this link
Dead animals report form [Event.]
Sounds interesting. I'll report a dead animal.
I select this link and then the skip-link -- at which point things start to go wrong. I hear:
Dead animals report form
(Start of form 2.)Table summary: *.
[1: Submit button.]
[2: Submit button.]
[3: Submit button.]
[4: Submit button.]
Table summary: *.
Table summary: *.
Table summary: *.
About This Form
This form may be used to report dead animals that need to be removed.....
Try as I might, I can't find a form on this page that will let me report a dead animal. Lots of 'submit' buttons, though .....
And what's all the 'Table summary: *.' entries about, I wonder?
A scan of the page in forms mode and table mode doesn't help.
A check on the <title></title> suggests I'm on the right page (Report it - Woking Borough Council) -- but where's the form?
The use of some text (hidden or otherwise) to tell me that this is a multi-page form would have been useful.
Still, when/if I discover that I've got to select the 2. Submit button, the form itself is quite easy to enter, except on the second/third? page where I hear the following:
Dead animals report form
(Start of form 2.)Table summary: *.
[1: Submit button.]
[2: Submit button.]
[3: Submit button.]
[4: Submit button.]
Table summary: *.
Table summary: *.
Table summary: *.
Details About the Dead Animal
Is the animal causing a danger to the highway? superscript *
[Not Pressed.]
Yes
[Not Pressed.]
No
What type of animal is it? [e.g. fox, badger.]
[Text.]
The problem here is that if your reader requires you to enter 'forms' mode to fill the forms data, you're going to hear:
Search this site: [Text.]
[Search: Submit button.]
[1: Submit button.]
[2: Submit button.]
[3: Submit button.]
[4: Submit button.]
Yes [Not Pressed.]
No [Not Pressed.]
What type of animal is it? [e.g. fox, badger.] [Text.]
.. with no idea what 'Yes' and 'No' refer to (unless you can remember from when you read through the form -- assuming that you did).
Anyway, that was the only page sequence that I had a chance to test. Maybe I was unlucky in picking this one.
.
Share:
Jake, do you mean these pages?
- Homepage
- Report it
- Dead animals report form (this is rather sad!):
- Contact Details (Page 1)
- Your Contact Details (Page 2)
- Details about the dead animal (Page 3)
- (Cannot advance to Page 4 without entering details for Page 3.)
- Contact Details (Page 1)
- Tables for layout.
- summary="*".
- Submit buttons for navigation: these should be hyperlinks.
- Multiple pages instead of a singe page. Scrolling a medium-length page is faster, more familiar and easier than navigating between several short pages.
- Must remember instructions between pages.
- Pagination is indicated by submit buttons. If you keep the multi-page approach (which you shouldn't), the pagination should just be text saying "Page x of y". If you press one of the buttons, you are taken to the page you are already on.
- At the first page, I had to click Next twice before it moved me to page 2.
- On page 2, Title is a drop-down list, not a text field. Has separate fields for House Name and House Number and each possible line of the user's address is a separate text box. Addresses differ. Just give a <textarea> with several rows labelled Address?
- Information icons have title attributes. These are sometimes longer than will fit in single-line tooltips in Firefox. They are too long to read before the timeout on Windows anyway, even if you can see all the text by using IE.
- Gaps between controls are created like this:
| Code: |
| <tr id="TR:JE8glFFUNxc" class="fieldtr">
<td colspan="2" id="TD:JE8glFFUNxc" class="fieldtr"> <div style="height: 10px;"> </div> </td> </tr> |
It's a good site overall, but there's lots of sub-optimal things throughout. Is 2.6kB of <meta> tags on every page really helping users? I doubt it. The extra HTTP requests from having 7 stylesheets. (8 for users of IE 7 or lower.) inner.css is only doing this:
| Code: |
| @import url(./content.css);
@import url(./layout.css); |
- screen.css merged from all media="screen" styles.
- print.css remains as-is.
- ie6.css remains as-is.
- ie7.css remains as-is.
Article7, your reasons for image replacement don't add up. I can detail why, if you like.
Nice to see a text/html document actually using HTML! Good use of headings, lists, display: block for navigation links, a:focus styles, yadda yadda yadda. I expect nothing less from you.
(EDIT) Just noticed all your href attributes for internal links begin with http://www.woking.gov.uk/. This can be shortened to just /. That saving is worth having throughout whole pages and whole websites. Incidentally, why not http://woking.gov.uk/? Double-barrel TLDs make short URLs more important. It currently reads like a naff radio DJ saying "Hi, you're listening to whuh-whuh-whuh Woking!"
(EDIT2) Just to be evil, I notice your favicon.ico is sent with the wrong MIME type.
(EDIT3) Linking this topic with your blog about the redesign:
| Andrew Green wrote: |
| The new site doesn’t have placeholder text, 10.4 be damned. |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
Yes, those are the pages in question.
I'm not sure how typical of the site it is, so I shall have a closer look over the Easter break.
I think that the problem is one of not checking all of the site, with someone who's not too familiar with the site doing the testing.
The use of some additional text would sort out most of the problems.
Also, as you point out, using 'submit' buttons in place of standard 'links' just helps to confuse things, as does putting a summary="*" in the tables.
If I had landed on the page and heard 'Dead animals report form: you are on page 1 of a 4-page form' and (eventually) 'go to the next page', it would have been easier to figure things out.
.
Share:
| Jake wrote: |
| I select this link and then the skip-link -- at which point things start to go wrong. |
Many thanks, Jake for your comments here. They're extremely useful.
As with so much, (almost) all eforms on the site are powered by a third-party system -- in this case AchieveForms. The site's CMS acts as a proxy between the user and the forms system, so that we can package the form up into our own site templates. This also allows us to tinker with the output using XSLT.
Using submit buttons to navigate the pagination of a multi-page form is an AchieveForms idiom. It may be possible to transform these to regular links using our filter, but I'll need to experiment with that. There may be a problem with using GET.
Having the first page of a form to state the purpose of the form and data protection issues is a Council idiom.
In their assessment of the forms, the Shaw Trust noted that it would be better for users of JAWS etc to have the text "Step 1", "Step 2" etc as the values of these buttons rather than just the numerals "1", "2". In the hope that it might be read instead of the value, I used the filter to add a title attribute of "Step 1 of 4" (or whatever) -- clearly, the title attribute isn't read aloud. So, I've now changed this to adjust the button value instead.
Does that improve matters? Should we have an (off-screen) piece of text describing the function of those buttons instead? Or as well?
The filter also now loses all those redundant summary attributes.
As for the problem with the radio form controls, I'm not sure how to fix that. The "yes" and "no" are (correctly, I believe) the <label>s for their respective radio buttons -- so I'm not sure how the actual question text should be associated with them collectively. Any pointers?
Cheers,
Andrew.
_________________
Andrew Green
Article Seven / Buy Our Honeymoon / Elements or Lower
Share:
| Cerbera wrote: |
| If you keep the multi-page approach (which you shouldn't) |
Some forms can get quite hairy, and parts of the form may depend on answers to previous parts of the form. I don't think there's a mandate that all forms should be single-page, irrespective of length, and I certainly don't believe there's an accessibility issue here, besides the behaviour of multiple submit buttons in speech software.
| Quote: |
| On page 2, Title is a drop-down list, not a text field. Has separate fields for House Name and House Number and each possible line of the user's address is a separate text box. Addresses differ. Just give a <textarea> with several rows labelled Address? |
This is to ensure data interoperability with the Council's CRM software.
| Quote: |
| Is 2.6kB of <meta> tags on every page really helping users? I doubt it. |
Talk to ESD about that. Note that the EGMS is mandated as part of the e-GIF.
Nonetheless, the bandwidth-optimisation of the site is very much still a work-in-progress. To the extent that the site doesn't crawl, I don't see it as an accessibility issue at this point.
| Quote: |
| Just to be evil, I notice your favicon.ico is sent with the wrong MIME type. |
That's fixed now.
| Quote: |
| Congrats on the Shaw Trust accreditation. Did they miss out these forms? |
No, they assessed the forms.
Cheers,
Andrew.
_________________
Andrew Green
Article Seven / Buy Our Honeymoon / Elements or Lower
Share:
| Phil Teare wrote: |
| Have you considered Talklets instead of dixerit? (interest declared) |
Not really my call, I'm afraid, Phil. But I'll certainly mention you guys to the Council's web manager.
Cheers,
Andrew.
_________________
Andrew Green
Article Seven / Buy Our Honeymoon / Elements or Lower
Share:
cheers _________________
creator of Talklets
Talklets ,
Share:
I very much sympathise with the difficulty of getting sensible interface design and markup out of 3rd-party controls. I commend what you've achieved so far and your responsiveness to feedback is admirable. I'm just pointing out there's more which could be done to aid all users.
Forms with different paths can suit multi-page forms. Sometimes they are better as completely separate single-page forms. This form always gives the same path, so it would be better as a single page.
Jake's feedback shows this multi-page approach has accessibility issues. It requires several navigation actions during form completion, with the re-orientation overhead that adds on users each time. Also, if you need a reminder of the instructions you must navigate between pages. If it were on one page, you could simply glance up or scroll up. You could remove all the pagination controls, making the form simpler still. There would only be 1 button instead of many, many buttons across several pages.
These issues affect usability for everyone, including but not limited to screen reader users. That makes them all the more important, imho.
| article7 wrote: |
| This is to ensure data interoperability with the Council's CRM software. |
Why does the address need to be split apart anyway? I can understand splitting the postcode from the other details but that's easy: pick out the final line. All other uses I can think of for the address would use it as one big lump.
Indeed, you might just ask for the postcode. The rest of the address can be looked up from the postcode (probably automatically) if it is needed. Convenience for users is paramount...especially since typical users type many times slower than you or I do!
| article7 wrote: |
| Talk to ESD about that. Note that the EGMS is mandated as part of the e-GIF. |
| article7 wrote: |
| To the extent that the site doesn't crawl, I don't see it as an accessibility issue at this point. |
| article7 wrote: |
| As for the problem with the radio form controls, I'm not sure how to fix that. The "yes" and "no" are (correctly, I believe) the <label>s for their respective radio buttons -- so I'm not sure how the actual question text should be associated with them collectively. Any pointers? |
| article7 wrote: |
| Using submit buttons to navigate the pagination of a multi-page form is an AchieveForms idiom. It may be possible to transform these to regular links [...] |
(EDIT) Linking this topic up with the website's news about the redesign. Have you considered URLs like http://woking.gov.uk/news/2008/03/redesign rather than http://www.woking.gov.uk/news?item=000047D9A27B.C0A801BA.00002359.000C to match the excellent ones elsewhere on the site?
(EDIT2) I notice the Site Map is a huge, nested list with no headings. I count over 400 links on that page. Surely that can't be accessible and usable? A map isn't made more useful by showing every pebble!
If it just showed the 1st and 2nd levels, that would make it easier to use. You could use <h2> for the top-level link and a <ul> for the 2nd level links in that section. This would enable heading-based navigation. It would also reduce intention, allowing better use of space. Giving it 2 or maybe 3 columns would reduce scrolling and further improve the use of space.
The search results use this for pagination:
| Code: |
| <p class="isys_pagination"><span>Page:</span> <a href="http://www.woking.gov.uk/search/isysquery/f81f570e-8388-4a85-9c89-30c5cbfe36c2/11-20/list/" class="isys_previouspage">Previous</a> <a href="http://www.woking.gov.uk/search/isysquery/f81f570e-8388-4a85-9c89-30c5cbfe36c2/1-10/list/" class="">1</a>..<a href="http://www.woking.gov.uk/search/isysquery/f81f570e-8388-4a85-9c89-30c5cbfe36c2/11-20/list/" class="">2</a>..<b>3</b>..<a href="http://www.woking.gov.uk/search/isysquery/f81f570e-8388-4a85-9c89-30c5cbfe36c2/31-40/list/" class="">4</a>..<a href="http://www.woking.gov.uk/search/isysquery/f81f570e-8388-4a85-9c89-30c5cbfe36c2/41-50/list/" class="">5</a>..<a href="http://www.woking.gov.uk/search/isysquery/f81f570e-8388-4a85-9c89-30c5cbfe36c2/51-60/list/" class="">6</a>..<a href="http://www.woking.gov.uk/search/isysquery/f81f570e-8388-4a85-9c89-30c5cbfe36c2/61-64/list/" class="">7</a> <a href="http://www.woking.gov.uk/search/isysquery/f81f570e-8388-4a85-9c89-30c5cbfe36c2/31-40/list/" class="isys_nextpage">Next</a></p> |
I like how there is no Previous link on page 1 of the results. And that the current page is delinked.
Perhaps using a heading for each result title would be better than than <li>? That way normal heading-based navigation would work and you'd have a better Document Outline. It would also be consistent with Google's use of <h2> to its results, which was probably done for a reason.
It's an outstanding website when taken as a whole and compared to typical websites. Just giving some (hopefully constructive) suggestions for improvement.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| article7 wrote: |
|
In their assessment of the forms, the Shaw Trust noted that it would be better for users of JAWS etc to have the text "Step 1", "Step 2" etc as the values of these buttons rather than just the numerals "1", "2". In the hope that it might be read instead of the value, I used the filter to add a title attribute of "Step 1 of 4" (or whatever) -- clearly, the title attribute isn't read aloud. So, I've now changed this to adjust the button value instead. Does that improve matters? Should we have an (off-screen) piece of text describing the function of those buttons instead? Or as well? |
It's better now:
Dead animals report form
(Start of form 2.)
[Step 1: Submit button.]
[Step 2: Submit button.]
[Step 3: Submit button.]
[Step 4: Submit button.]
About This Form
This form may be used to report dead animals that need to be removed.
For more information about reporting dead animals on our website click here
I'd suggest that 'Step 1' shouldn't be marked up as a link as (already mentioned) it just loads the same page again.
My own thoughts are that some 'invisible' text should be present to explain that this is a multi-page form, and how it works.
| article7 wrote: |
| The filter also now loses all those redundant summary attributes. |
Agreed.
| article7 wrote: |
| As for the problem with the radio form controls, I'm not sure how to fix that. The "yes" and "no" are (correctly, I believe) the <label>s for their respective radio buttons -- so I'm not sure how the actual question text should be associated with them collectively. Any pointers? |
Encompass the question and radio buttons with a <fieldset>, and with the question as a <legend>.
Depending on the reader in use this will precede each 'yes/no' with the question, or will precede the first label ('Yes') with the question.
e.g.
Is the animal causing a danger to the highway?: Yes; Yes [Not Pressed.]
-- or something similar
[edit] Providing the question in that way also helps on those occasions where the selection of the radio button is mandatory i.e. a 'red asterisk' .... or 'superscript asterisk' as my reader tells me
.
Last edited by Jake on 22 Mar 2008 06:20 pm; edited 1 time in total
Share:
| Cerbera wrote: | ||
Why does the address need to be split apart anyway? I can understand splitting the postcode from the other details but that's easy: pick out the final line. All other uses I can think of for the address would use it as one big lump. Indeed, you might just ask for the postcode. The rest of the address can be looked up from the postcode (probably automatically) if it is needed. Convenience for users is paramount...especially since typical users type many times slower than you or I do!
|
The address is probably going to be stored in a database. The database will have been set up with the address split into its various components.
Holding the data in this form helps when it's necessary to extract it or analyse it.
Also, if the address is to be used in any form of mailing, then the address would need to be held in its component form for use with (for example) de-duping software.
.
Share:
| Jake wrote: |
| The address is probably going to be stored in a database. The database will have been set up with the address split into its various components. |
| Jake wrote: |
| Holding the data in this form helps when it's necessary to extract it or analyse it. |
| Jake wrote: |
| Also, if the address is to be used in any form of mailing, then the address would need to be held in its component form for use with (for example) de-duping software. |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| Cerbera wrote: |
| I'm just pointing out there's more which could be done to aid all users. |
I do appreciate that, Ben -- and I'm sorry that my previous reply was a bit curt. Thursday was surprisingly manic, and I'm a moody sod. Thanks for taking the time to examine the site so thoroughly.
| article7 wrote: |
| Talk to ESD about that. Note that the EGMS is mandated as part of the e-GIF. |
| Cerbera wrote: |
| I thought you could use a <link> element to an XML file for this? If you can't, they need to allow that and promote it as the recommended method. That way it would only get loaded by things which make use of it. |
The standard (which hasn't been updated since 2004) recommends having linked RDF metadata in addition to (X)HTML metadata. Nonetheless, we already have a very rudimentary RDF output stream built into the CMS, so (when there's time to do so) I may well look into developing this further.
| Cerbera wrote: |
| Group the radio buttons using <fieldset> and label the group with <legend>. You can hide the <fieldset> borders and position the <legend> off-screen if the default styling wouldn't suit the design. |
Thanks also to Jake for the same solution here. I'll see if my XSLT-fu is up to the challenge and report back.
| Cerbera wrote: |
| I notice the Site Map is a huge, nested list with no headings. ... If it just showed the 1st and 2nd levels, that would make it easier to use. |
It goes three levels deep, and no further. The consensus here seemed to be that three levels was about the right level of detail. I have, however, switched the top level to headings rather than list items.
| Cerbera wrote: |
| The search results use this for pagination... |
ISYS, usefully, allows you to adjust its output templates faily extensively. The pagination control, however, isn't something that can be adjusted through the templates, so we either have to use the XSLT filter or use a bunch of regexes on it. Consequently, changing this isn't at all straightforward. I've removed the empty class attributes, though.
| Cerbera wrote: |
| Perhaps using a heading for each result title would be better than than <li>? That way normal heading-based navigation would work and you'd have a better Document Outline. It would also be consistent with Google's use of <h2> to its results, which was probably done for a reason. |
I honestly had no idea Google did that. It's surprising really that a list of search results shouldn't be marked up as a list, but I take your point about navigating the page through its list of headings.
Cheers,
Andrew.
_________________
Andrew Green
Article Seven / Buy Our Honeymoon / Elements or Lower
Share:
| article7 wrote: |
| ...and I'm a moody sod. |
| article7 wrote: | ||
|
I measure the <div id="content"> as being 10,588 pixels tall. That's an awful lot of scrolling (or speaking or feeling)! Thinking laterally, how about reducing the amount of vertical space between the innermost items? Using sitemap.css, perhaps something like this:
| Code: |
| /*
Content: 14.2667px 1st items: 17px 2nd items: 13px 3rd items: (none) */ #content li { margin-top: 0.462em; margin-bottom: 0.462em; list-style: disc; font-weight: bold; font-size: 1.192em; } #content li ul { margin-top: 0; margin-bottom: 0.462em; } #content li li { margin-top: 0; margin-bottom: 0; list-style: circle; font-size: 0.765em; } |
- a site-wide search box;
- an A-Z index;
- and a flat navigation list.
Best way to provide a Site Map covers how I trimmed out Calthorpe Park School's site map with the help of Accessifiers.
| article7 wrote: |
| It's surprising really that a list of search results shouldn't be marked up as a list, but I take your point about navigating the page through its list of headings. |
- A title.
- An excerpt from the document.
- A URL.
- <h2>
- <p> or <blockquote><p>.
- <p><code>.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum