Accessibility

[kiwibrit]

I have had a look at Zoom - and installed it on the club site I do as a freebie, mostly so that I could think about Zoom for the company site.

It's very good - but accessibility could be better. I found myself having to amend the search.php file to introduce labels for the radio buttons (WCAG checkpoint 12.4). I was also disappointed to see transitional coding being used.

Even so, a very useful tool, which can be knocked into basic accessibility requirements without too much grief.

But I hope there are accessibility improvements in the next issue.

[David]

Thanks for the comments. What is wrong with transitional coding?

Your probably going to tell me that we should be using strict coding I guess?

But our transitional coding search pages are validate HTML (well XHTML actually)

But your strict coded home page is not.
(Failed validation, 4 errors)

Your "Accessibility" page is also broken.
(Sorry, there has been a page error. The server could not complete your request.)

-----
David

[quintic]

Accessibility and semantic markup

kiwibrit, I've also modified search.php to add a label to the basic search box, which is the only one I use.

As regards Strict vs Transitional, I modified search.php to write HTML 4.01 Strict, to match one of my sites. All that was needed for Strict was to enclose the internals of the form in a div. So the generated HTML is almost Strict! Then to convert to HTML required only a simple search/replace of ' />' to '>'.

I'd like to see the search results marked up as an ordered list, or possibly as a definition list. That would make a little more sense structurally and to a screen reader than the divs currently used.

On the subject of semantic markup, it would also be nice to highlight the matched text using a styled [i] or [b], rather than a styled <span>. Again, this would help screen readers.

[kiwibrit]

Thanks for the comments. What is wrong with transitional coding?

Your probably going to tell me that we should be using strict coding I guess?

Yes.

But our transitional coding search pages are validate HTML (well XHTML actually)

But your strict coded home page is not.
(Failed validation, 4 errors)

Ouch! Corrected.

Your "Accessibility" page is also broken.
(Sorry, there has been a page error. The server could not complete your request.)

Don't understand that. Working here at moment, and server is normally reliable. If it's still glitching your end, I'd be grateful for a headsup.

[kiwibrit]

quintic, good points. I don't understand why Wrensoft are using XHTML (see webmasterworld 8-page thread Why most of us should NOT use XHTML, [Subscription required] and why strict coding is not being used. That said, and I don't have time to check at the moment, I think there is a problem with ordered lists in strict coding.

This seems to be a really great search engine, intelligently thought through, marred by easily-sorted coding detail in the output.

Perhaps Wrensoft should drop by Accessify's forum for accessibility comment from authors more experienced in accessibility coding than I.

[quintic]

There's no problem with ordered lists in strict HTML. (An unordered list would also be an improvement on the divs currently output.)

[David]

The use of XHTML allows the results produced by Zoom to be more easily parsed by external applications. And from what I have read, as long as Zoom spits out validated well formed XHTML it should be OK.

Other than religious type arguments, it is hard to see any benefit in changing to HTML4 strict (or any other mark up specification). We are not aware of any case where Zoom doesn't work at the moment. So why 'fix' it if it isn't broken? If anyone can give a practical benefit we'll consider it.

Note that we plan on adding a clean pure XML output option in the future.

I also don't agree with the use of the [i] or [b] tag for a highlight. These tags are very likely to be used elsewhere on the same site or even on the same page as the search results. We want people to have the ability to make a highlighted text different from emphasised text on the same page.

------
David

[David]

Your "Accessibility" page is also broken.
(Sorry, there has been a page error. The server could not complete your request.)

Don't understand that. Working here at moment

No it isn't. The URL is wrong on the search page.
http://www.castlehillclub.com/sitese...essibility.htm

-----
David

[quintic]

The use of XHTML allows the results produced by Zoom to be more easily parsed by external applications. And from what I have read, as long as Zoom spits out validated well formed XHTML it should be OK.

Other than religious type arguments, it is hard to see any benefit in changing to HTML4 strict (or any other mark up specification). We are not aware of any case where Zoom doesn't work at the moment. So why 'fix' it if it isn't broken? If anyone can give a practical benefit we'll consider it.

A different perspective is: why would you choose not to respect the DOCTYPE that the customer specifies in search_template.html? If the user changes it to HTML 4.01 Transitional, why not output transitional HTML? If the user changes the DOCTYPE to HTML 4.01 Strict, why not output strict HTML? (Requiring a containing <div> within the <form>, for instance.) Strict would also be Transitional, of course.

Under certain circumstances, writing non-Strict markup to a document with DOCTYPE = HTML Strict can cause the browser to switch from standards mode to quirks mode, with possibly different rendering results. See, for instance, Picking a Rendering Mode. I haven't yet checked whether the non-Strict markup output by Zoom could trigger quirks mode in a Strict document.

I also don't agree with the use of the or [b] tag for a highlight. These tags are very likely to be used elsewhere on the same site or even on the same page as the search results. We want people to have the ability to make a highlighted text different from emphasised text on the same page.

The <em class="highlight">highlighted text would be different by virtue of its styling. For example, .highlight {background:#FFFF40}, or em.highlight {background:#FFFF40}.

You'd also need to include CSS to switch off the default behaviour of [i], so we'd have: .highlight {font-style:normal; background:#FFFF40}.

Now we have the possibility, as in the case of the styled <span>s that Zoom currently uses, that [i] is styled in the user's CSS. For example, the user might have specified em {color:#FFFF40} in an external CSS file, which, combined with the above, would produce invisible text! The same thing could happen currently if the user's CSS specified span {color:#FFFF40}. However, it is more likely that a user would style the [i] rather than the <span>, so that must be counted against my suggestion. (Though of course the user would be able to switch off any [i] style they didn't want applied to highlighted results, so this is not an insuperable obstacle.)

I'd like to see the ability to specify HTML markup for each section of the output. Instead of a single there could be a section, a , a , a , and so on. Each would output pure text, leaving the user to add the appropriate HTML and CSS. This would give much greater flexibility, and could be hidden behind an 'Advanced' tab so that those who don't want the flexibility needn't be bothered by it.

Is there any chance of that in V5?

[kiwibrit]

Your "Accessibility" page is also broken.
(Sorry, there has been a page error. The server could not complete your request.)

Don't understand that. Working here at moment

No it isn't. The URL is wrong on the search page.
http://www.castlehillclub.com/sitese...essibility.htm

-----
David

Thanks. Sorted.

[kiwibrit]

The use of XHTML allows the results produced by Zoom to be more easily parsed by external applications. And from what I have read, as long as Zoom spits out validated well formed XHTML it should be OK.

Not a biggy. But I am surprsed you don't at least offer the option.

Other than religious type arguments, it is hard to see any benefit in changing to HTML4 strict (or any other mark up specification). We are not aware of any case where Zoom doesn't work at the moment. So why 'fix' it if it isn't broken? If anyone can give a practical benefit we'll consider it.

"Religious" is a strangely emotive word to use. And I'm quite surprised you seem to think that writing output for strict presents you with a significant problem. W3c recommends it (see "What should you include in your requirements list?") but, interestingly, the UK government advises transitional coding be considered for its sites - and it also endorses XHTML

Provided I get no complaints with the output from those using screen readers, I shall be content. Otherwise I guess I can hack the output myself.

I am getting round the teething problems on the club site. My MD was impressed when I showed it to him today, and has asked me to by Zoom for the company site.

[Ray]

Thanks for the posts. We do understand the points being made and recognize that there are certain advantages to go with any one specification over another. And certainly, we will continue to make changes necessary if we believe the improvement is quantitative and justifiable at that time.

The problem however is that there is no ideal specification, and the public opinion on these matters changes rapidly - it wasn't long ago when XHTML was praised as the be all and end all (and it still is these days, depending on who you talk to). In fact, part of the reason we moved to XHTML in the first place was because we had many users e-mailing us and asking us to do so.

While it would be nice to be able to offer a list of output choices, it is not so practical to support everything - and a universal solution would require a fair amount of work (remembering that we also support at least 4 different scripting platforms - we would essentially have to code 4 new output engines which switches specifications for output upon demand). So we have to weigh our priorities and considering that the practical gain from this is relatively minor - that's why we ask for more practical reasons for when strict encoding would be required (besides it just being a nice thing to have).

At this point, our current policy is that we simply provide XHTML 1.0 Transitional encoding, and we plan to add a raw XML output option.

[kiwibrit]

OK, my take FWIW. Strict coding gives a greater shot that various browsers will work correctly on different platforms using differing OS. Transitional coding is there primarily to cope with legacy pages. Eventually, it may not be supported, so I personally don't like coding new pages in it. However, if that ever happens, it'll be up to Wrensoft to cope with an upgrade for Zoom, so I don't have a major worry. Most accessibility gurus seem to think that strict gives more screen readers a chance to interpret a page correctly. About the only things that transitional coding does not support is target="_blank", and start="", which can be a pain in some[list=1], where a list has been interrupted. I have come to the view that most links should not open in new windows. But I know that is controversial, and I have not always thought that.

The UK government advice may be rather dated. I understand that browsers not coping with strict and associated CSS would have to be of the IE5.0 era, or before.

I don't feel religious about it, though

PS - am becoming very pleased with the club site search configuration. Have bought the standard version for the company, and hope to have it up soon.