Re: the use of the <br /> tag

Hi Charles

If you wouldn't mind I'd like to hear of your concerns regarding the use of
the <br> tag when used with slabs of text.

I confess to using <br /> a little too liberally for formatting purposes
and am curious to learn what impact this may have on accessibility.
Also, when used within <p></p> to prevent line wrapping.

While I'm on the case - are there any accessibility issues with the use of
&nbsp; to likewise prevent line wrapping?

Cheers
Michael
---------------------- Forwarded by Michael Virant/NRE on 12/01/2004 11:59
AM ---------------------------


charles@sidar.org@w3.org on 12/01/2004 04:48:59 AM

Sent by:    w3c-wai-ig-request@w3.org


To:    matt@kbc.net.au
cc:    w3c-wai-ig@w3.org

Subject:    Re: Accessible Survey Creation - Authoring Mechanism



Hi Matthew,

this looks like an interesting rpoject - not least as a personal
learning exercise for you, since the way tolearn seems to be by doing
:-)

Couple of comments below:

On Monday, Dec 15, 2003, at 23:24 Europe/Rome, Matthew Smith wrote:

> The work in question is a Web-based survey tool for use in schools in
> this region.  The content authors will have no control over
> formatting, other than being able to break the questions into
> paragraphs.  (Text is presented inside <p> ... </p>; a single line
> break in the input will be substituted with <br /> at time of page
> display, more than one line break with </p><p>.)

I'm not a great fan of <br />, but I do like using lists. Have you
looked at some other text-to-html converters to see if they'd do the
job? (txt2html is a PERL script in some incarnation, and Wikis tend to
do this too...)

> Despite having tight control over document structure, the content
> author can still 'break' the overall accessibility of the page.

Naturally :-) The point is to help them avoid this if they want to.

> 1.1)      There is a Perl module that can produce a Flesh-Kincaid
> readability score.  This could be used to provide feedback to the
> content author.

Are you interested in looking separately at the idea of linking a
vocabulary, and checking that everything in the document is in the
vocabulary? This is a similar approach, but potentially more powerful
than a Flesh-Kincaid, since it can allow for things like automated
dictionary lookup on uncommon terms or phrases.

> 1.3)      Appropriate graphic representing the question to be provided
for
> each question.  (The upload form will force a non-null alt value to be
> provided.)

I'd suggest that instead you have a separate button which says "this
image adds nothing" which puts in a blank alt and a longdesc.

> 1.4)      Readability information for 1.1 and 1.2 to be embedded as
> metadata so that we can 'crawl' the questions for possible readability
> problems.

I'm interested in how you do this...

> 2.1)      Maintain an glossary of ALL abbreviation used in text.  There
> would be two levels - a simple expansion to populate the <abbr></abbr>
> and a longer textual description which would be accessed by
> hyperlinking the term in the text.  (The glossary mechanism would
> receive a query string which would allow the user to return to exactly
> where they left off, having read the full text.)

See my question above about applying this approach more generally to
vocabulary...

> 2.2)      As the content author enters questions, anything that looks
like
> an abbreviation (rule: more than one capital in a word) will be
> checked against the glossary.  The author will be prompted to provide
> definitions for the term, including an option 'this is not an
> abbreviation/acronym'.  The mechanism is much like that of a
> spell-checker.

cheers

Chaals
--
Charles McCathieNevile                          Fundación Sidar
charles@sidar.org                                http://www.sidar.org

Received on Sunday, 11 January 2004 20:06:33 UTC