[WSG] Off Topic - with apologies
Directed to standards aware developers in the SF Bay Area: http://jobs.stanford.edu Job ID# 32035 ...back to your regularly scheduled list-serve, already in progress. Cheers! JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Investigating the proposed alt attribute recommendations in HTML 5
Lachlan Hunt wrote: > > What should an authoring tool (like Dreamweaver) insert by default > when a user adds an image and immediately dismisses the alt text > prompt? (It currently omits the attribute unless the user explicitly > selects "" or types in some text.) Currently, most screen technology would prefer alt="", as this signals that the value string for ALT is... Nothing. Not great, to be sure, but better than "DC10567.jpg" or echoing back information provided elsewhere (through @caption or @title or similar) > > What should wikipedia use by default for images used in articles? (It > currently redundantly repeats the image caption in both the alt and > title attributes) Wikipedia should allow users to specify alt text (it currently does not). By design, when uploading an image, there should be a default table in the DB for alternative text. Given the many times that images in tools such as wikipedia re-use images, content authors should be prompted to use the default alternative text, or supply 'new' alt text. Currently wikipedia's answer is to not allow content contributors to provide *any* alt text. > > What should sites like Flickr, Photobucket, Facebook, MySpace, etc. > generate and insert? Same as above > > What should forums (e.g. phpBB) or blogs (e.g. Blogger) use? Same as above > > What should an email application insert when a user emails an image > to a friend? This one is trickier, and makes presumptions that are not in evidence. For example, this presumes that everyone is using HTML rich email, a bad presumption. It secondly presumes that personal one-to-one correspondence might be shared, a bit of a stretch. However, assuming that a user is creating HTML rich email in an authoring environment like Outlook, the tool should prompt for alt text similar to what tools such as Dreamweaver should do, and provide the same fallback: alt="". In online environments (Yahoo!Mail or Gmail or what-ever) then they should handle this question like Flickr and Photobucket would. Nothing in the world will be able to force a content creator to do the right thing, however entrenching the option to do the wrong thing should never be considered as part of an emergent spec. If currently the tools don't get it right, fix the tools, don't change the rules. JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What do we say if we don't say "click"?
Michael MD wrote: > > btw that "99.99%" was never intended to be used as some kind of > reliable statistic! > so please don't quote it as such! > - it was only a guess about something - perhaps I should have just > said something like "most"... :-) Yep, I know that. The point is that too often we take ideas for granted, and the statement that suggested that such a significant percentage of JS enabled browsers will be using a pointing device is patently false. Even "most" can be misleading - "many" is probably most accurate, if still inconclusively vague. As well, I know many, many power-users who rarely use their mouse, preferring keyboard navigation, so I'm not sure how there can be any correlation between JavaScript and a mouse/pointing device anyway. > > btw it seems that there are quite a few people out there who browse > on their phones but do not often browse on a PC... > so I don't think we can expect them all to be familiar with many of > the conventions we might take for granted! Exactly, and I've yet to encounter a cell phone with a mouse attached . Cheers! JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What do we say if we don't say "click"?
Terrence Wood wrote: > John Foliot wrote: >> semi-credible stats showing that 4% of users cannot (do not?) support >> JavaScript [http://www.thecounter.com/stats/2007/March/javas.php] > > Granted, this appears to be more reliable than 99.9% - but isn't > javascript required in order for thecounter.com to gather stats, or > do they use web bugs? > > I think it is (semi) safer to say 4% of visitors to sites using > thecounter.com counters do not have javascript enabled =) > No argument, which is why I said semi-credible... like most web stats they are subject to numerous variables. However, for the sake of discussion, they can at least be referenced by all, unlike the incredulous 99.99% number I was questioning. JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What do we say if we don't say "click"?
James Leslie wrote: > On a related note, though not involving galleries, I find a lot of > our clients want to have linked text along the lines of "Click here > for more details on product x". I have managed to fairly much insist > that we always use the entire sentence as a link to show context, > rather than just the "click here" that they tend to want being the > only linked part. The main reason I have not been able to get rid of > the "click here" part altogether though is due to an absence of a > suitable alternative that incorporates other technologies... Does > anyone have any suggestions for these circumstances? One thing I try to encourage is to rephrase the statement to actually present the URL as part of the "on screen" text, for example: "...More information regarding foobar can be found at: link_uri." 1) almost everyone recognizes a structured URI as being a link, there is no ambiguity there 2) surprisingly, some people still print out web pages, and providing the actual uri in print benefits these people 3) making the uri the actual link text ensures that the link text is unique for the page 4) this is technology agnostic JF *blah blah in uri above = title, class or id declarations as required/desired *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What do we say if we don't say "click"?
Michael MD wrote: > interesting discussion > > I get a lot of mobile phone users here. > "click" would definately not be a suitable word to use on any page > mobile phone users are likely to look at. > > ...however I might use that word on pages that require javascript > such as those that use an external api to display maps. > The only people able to use those pages are people using a web > browser that can execute javascript... and 99.99% of such users would > be using a mouse or a pointing device designed to emulate a mouse! Interesting. Can you point to the source of this statistical declaration? I can point to semi-credible stats showing that 4% of users cannot (do not?) support JavaScript [http://www.thecounter.com/stats/2007/March/javas.php], but I'm curious as to where you can state that 99.99% of user would be using a mouse or similar pointing device. Hard statistical data like this is very difficult to come by, and so any credible source is interesting to both myself, and I'm sure others. Cheers! JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] What do we say if we don't say "click"?
Brian Cummiskey wrote: > I've been using "View Larger Image". > > something like this: > > src="small.jpg" alt="" />View Larger Image > > > Good discussion. :) Let's introduce a new slant to this: what happens if there are 16 thumbnail images in a gallery (4 up, 4 across)? Are you going to write: View Larger Image ...16 times? You *CANNOT* expect that the title attribute will be voiced by a screen reader, as this is directly affected by the verbosity setting established by the end user. If a power user sets verbosity to minimal (Advanced in JAWS, which has I believe 3 settings: Beginner, intermediate and advanced, with granular options on top of that such as "Words Include Symbols" - see the Freedom Scientific site for more details, and remember that this is *just* JAWS, there *are* other screen readers out there...)... At any rate, if they set it to advanced then JAWS usually does not read aloud the title attribute. So what you will have then, when bringing up a list of links on the page, is 16 unique links with the identical link text - hardly user-friendly or accessible. One way around this would be to announce prior to the image array to "Click on any image to view a larger version" (or similar). Another way, if the image is being populated via a database, would be to echo back the unique image name as part of the link text; this way, each link has unique text associated to it: - Larger Image ...for example. Placing the image title first in the link text will eliminate the annoying array of 16 unique links all starting with the same words, useful when the user orders the links alphabetically. Just some more to think about... Oh, for the most part, while avoiding the phrase "Click" may seem to be politically correct, it has become so common that even non-sighted users get it - it's like my blind friends saying "see you later": no harm, no foul. Cheers! JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] PopUp windows
Paul Novitski wrote: > You'll want to warn users, e.g. with a title/tooltip that says > something like "(Opens in a new window)." I've been told by a small > number of screen-reader users that this solves for them the > disconcerting problem of windows popping open with back buttons > disabled. Late to the party: This presumes of course that the user-agent will either produce a tool-tip, and/or that a screen reader has been configured to read aloud the title attribute - two conditions I would not bet the farm on... JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Today's lesson: "Respect" - be courteous up or leave
Lachlan Hunt wrote: > Unfortunately, top posting (or failing to quote at all) is often the > result users of broken e-mail clients (usually Outlook or some web > based mail). I find the best approach is to just set a good example, > and hope that others eventually get the idea and/or switch mail > clients. For those users married to their MS Office suite (and thus Outlook), you may be interested in this: http://home.in.tum.de/~jain/software/outlook-quotefix/ Problem solved. JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist WATS.ca - Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
[WSG] ACCESS + KEY still = ACCESSKEY
With apologies for cross posting. Dear Friends, For the many that know me, you will know that a post to any of the lists I subscribe to on the topic of ACCESSKEY will automatically receive a response from me. I think by now my position is abundantly clear on this topic. When I first heard that XHTML 2 was deprecating ACCESSKEY in favor of the ACCESS element and the ROLE attribute, my initial reaction was, "Finally, they will get this right and a predictable, useful, stable means will finally emerge to provide keyboard navigation to those that can truly benefit from it". For while I have continually decried the mess and potential for harm that ACCESSKEY presented, I have always supported and advocated for a better way, and we publicly applauded the W3C for "getting it" too (Aug. 14, 2004 - http://www.wats.ca/articles/thefutureofaccesskeys/66). Along the way however, the ACCESS element has been shackled with the "KEY" attribute, allowing the possibility for the content author to dictate a specific key binding to one or more of the access points, in effect, I believe, replicating and perpetuating many of the most serious issues with ACCESSKEY: keystroke conflicts, little or no conflict resolution, internationalization issues, lack of an existing or persistent standard, etc. And so I have asked the Editors of the XHTML 2 Draft Recommendation to remove the KEY attribute from the specification. The full text of my request is published on the WATS.ca website: http://www.wats.ca/articles/xhtmlroleaccessmodulestillflawed/80 I ask that you take the five minutes required to review my request, and if you believe, as I do, that the KEY attribute has no place in XHTML 2, then I urge you to say so to the Draft Editors at [EMAIL PROTECTED] Remember, "The World Wide Web Consortium (W3C) is an international consortium where Member organizations, a full-time staff, AND THE PUBLIC work together to develop Web standards." (http://www.w3.org/Consortium/) Thank you. JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
RE: [WSG] 'em' versus '%'
Felix Miata wrote: > > No, it's not 16px. It's whatever size the user's browser default is > set to. In most modern browsers, it just happens to start at 16px in > most cases, but that is partly by accident, and is subject to user > adjustment in multiple ways. The W3C has specified 16px/96ppi as a standard default text size, and most modern browsers on the Macintosh and Windows platforms have honored that specification since 2000*. (Alas, that rules out Netscape 4.x - grin) None-the-less, today's Standards compliant browser generally renders a default EM as 16 pixels. (See the W3C CSS1 Specifications at www.w3.org/TR/1999/REC-CSS1-19990111#length-units plus the Errata Notice correcting the original CSS1 spec. www.w3.org/Style/css1-updates/REC-CSS1-19990111-errata.html) JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
RE: [WSG] computer arts mag article/review
Andreas Boehmer [Addictive Media] wrote: > From my personal perspective, Dreamweaver > has a fantastic coding view similar to Homesite, with the additional > features of FTP, CSS and Site Management. Uhm... It *is* HomeSite, which Macromedia bought to add to their Dreamweaver Suite (they also bought ColdFusion, which shipped with HomeSite as the editing environment, eons ago). You can still purchase Homesite as a stand-alone app, and this old dog still swears by it; I use it daily. JF ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Censorship (was RE: [WSG] IE Showing Transparent - APOLOGY)
Ingo Chao wrote: > Rick Faaberg wrote: >> Where do we draw the line on these sites? > > The reason why this did not happen before on the WSG mail list is > because no poster before did have problems in drawing a line for > himself. > > We should not change this unwritten agreement. Please do not impose your personal morality on this list. I do not believe that we should be censoring materials based solely on content. I *DO* agree that when providing links to examples where the content *may* be of a potentially offensive or questionable content, that it be indicated clearly up front, which did not happen this time. However, the development question it's self was both legitimate and fair game for a list on web standards and web development. What next? No links to religious sites? To pro-choice/anti-abortion sites? To sites dedicated to gay rights and same sex marriage? Who decides where the "line" is drawn? No, I believe posters to this list have a personal and PROFESSIONAL obligation to flag sites containing potentially 'incendiary' content, and then readers can apply their own moral judgment as required (and perhaps this should be added to the List's Guidelines / Rules of Participation: http://webstandardsgroup.org/mail/guidelines.cfm, with failure to do so an actionable offense). Anything else is offensive _to me_! JF -- John Foliot Perth, Ontario ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Staying on topic (was RE: [WSG] Accessibility, the possibilities)
Stuart Sherwood wrote: > >> Hi All, >> If you pass all these test, does this exhaust all accessibility >> issues or are there more? >> Stuart, There are also the "soft" tests - often these deal with areas of cognitive issues, from dyslexia to English as a second or third language, etc. Consider the requirement for appropriate and descriptive ALT text... What is appropriate, and further, who decides? Then there is the whole issue of "readability" - test such as the Flesch-Kincaid Grade Level Score can give you an idea if your content is written in language appropriate for the site's intended audience, but it's hardly an exact science. (http://wats.ca/resources/determiningreadability/1). There are also issues surrounding appropriate use of tables, list types, etc. which require judgment calls. Here, once the appropriate container has been chosen (UL, OL, table?), you must then check to ensure that they have been constructed appropriately - for example does your table have (or even require) a summary? Scope / headers & ID, etc.? As for testing tools, in addition to the ones already mentioned, we have collected a number of other "gadgets" which can be of assistance: http://wats.ca/resources/testingtools/44 Geoff Deering wrote: > > http://www.w3.org/TR/WCAG10/full-checklist.html > http://www.w3.org/TR/WCAG10/checkpoint-list.html > > I think there are P3 checkpoints that are not covered here that you > would need to check manually. There are in fact checkpoints under all three Priorities which require "brain" intervention - they simply cannot be tested mechanically. Try running a page through something like Cynthia says (http://www.cynthiasays.com) will quickly show you what needs to be manually checked. Cynthia says also provides a fairly extensive chart of what and how their tests are run (http://www.cynthiasays.com/Standards/CynthiaVersusBobby.htm) > > Just as a side issue, there is a lot of debate in the accessibility > community about the merit of using accesskeys, tabindex, etc. Did somebody say accesskeys? Whoa-boy... Using Accesskeys - Is it worth it?: http://www.wats.ca/articles/accesskeys/19 More reasons why we don't use accesskeys: http://www.wats.ca/articles/accesskeyconflicts/37 Accesskeys and Reserved Keystroke Combinations: http://www.wats.ca/resources/accesskeysandkeystrokes/38 Link Relationships as an Alternative to Accesskeys: http://www.wats.ca/articles/accesskeyalternatives/52 The Future of Accesskeys: http://www.wats.ca/articles/thefutureofaccesskeys/66 > > IMHO, many accessibility practitioners aim for WAI-AA, whilst > incorporating the most practical of the WAI-AAA checkpoints to aid > accessibility. As a general assumption, this is a relatively fair statement. Please remember that the WCAG is now 6 years old (May 1999), and it's showing it's age. Regrettably, some developers must adhere slavishly to the checkpoints - often creating more problems than they are solving, but that is simply due to the fact that the Guidelines were never written to be Standards - but are now serving that role more often than not. If you *do* have the luxury of being flexible, shooting for a WCAG AA+ "standing" is probably your safest position, but determining that "ranking" cannot be measured by simple tools alone - a clear and experienced understanding of the issues will always be required. The clear understanding can come from hanging out in forums such as this one, the WAI-IG (http://www.w3.org/WAI/IG/), WebAIM (www.webaim.org/gettinghelp/) and GAWDS (the Guild of Accessible Web Developers - http://www.gawds.org/discuss/). Many of the regulars on these lists are only too happy to lend a hand and provide answers, etc. when asked. Experience on the other hand takes time... But it's really worth the wait. HTH JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
RE: [WSG] IE Madness
Patrick Haney wrote: >> Internet Explorer cannot open the internet site http:// >> www.fifeweb.org/wp/events/evnt_ga_res_2005_01.html. Operation >> aborted. >> >> It seems as if IE is striping off the #top fragment. >> >> Anyone know how to fix this? > > Bob, > Late to the party, but I cannot replicate this problem (IE 6.0.2 / W2K). FWIW... JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
[WSG] RE: Stupid Questions? (was RE: [WSG] "display: inline-block": valid or not? W3C validator says not.)
Patrick Lauke wrote: >> John Foliot - WATS.ca > >> There is no such thing as a stupid question (although >> occasionally we will see stupid responses...) > > You tell 'em John :) > > P As a point of clarification, when I say stupid responses, I meant in the form of condescending or mean responses, rather than factually inaccurate responses (which sometimes *do* crop up, but not that frequently). My concern was that a "new" member felt intimidated to ask a question here, which made me sad... JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Stupid Questions? (was RE: [WSG] "display: inline-block": valid or not? W3C validator says not.)
SunUp wrote: > I do realise this is probably a very stupid question, and it's more > than a little scary asking a stupid question on this list, but I'll > wear the result if it means I can understand what I've done wrong. > > Thanks, > sunny. Goodness Sunny, There really is no such thing as a stupid question - please, I really hope that this list has not reached the point that newer subscribers feel intimidated to ask questions. Your question was both valid and well posed. Hey everybody! There is no such thing as a stupid question (although occasionally we will see stupid responses...) Cheers all! JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
RE: [WSG] Table header
Patrick H. Lauke wrote:
> Lea de Groot wrote:
>
>> The thead tag is the key -
>
> If you're using thead, you may as well go all the way and add a tbody
> as well...
>
>
>
>
> IDVar 1Var 2
>
>
>
>
> ID VALUE
> Var 1 value
> Var 2 value
>
>
>
Heck, if you're going to go all the way, why not also include the
(which comes after the , but before the and
essentially mimics the - this is useful for larger tables).
Then, if you want to get "real fancy", and you have a larger table, you
can set the height of the and make it scroll. While not
supported in all browsers, those that don't will simply default to a
full table:
Sample at: http://wats.ca/resources/accesskeysandkeystrokes/38
Cheers!
JF
--
John Foliot [EMAIL PROTECTED]
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Accesskeys (Was RE: [WSG] Re: digest for wsg@webstandardsgroup.org)
Josh Rose wrote: > > What I'm trying to do is have the accesskey underlined, it works fine > in Firefox and Opera (wayhey), but in IE 6 the a:first-letter works > fine, but a:hover doesn't at all (it does without a:first-letter > though) and in Netscape 7 the a:first-letter doesn't work at all > (just netscapes css support?) but a:hover does. Phew. > > The CSS is probably a bit bulky, but go easy on me, I'm newish to > this. > > Any ideas? If at all possible I'd like to avoid CSS hacks. > > Thanks, > Josh. En Francais eh? Bienvenue! Josh, Accesskeys? May I suggest you review the following? Using Accesskeys - Is it worth it?: http://www.wats.ca/articles/accesskeys/19 More reasons why we don't use accesskeys: http://www.wats.ca/articles/accesskeyconflicts/37 Accesskeys and Reserved Keystroke Combinations: http://www.wats.ca/resources/accesskeysandkeystrokes/38 Link Relationships as an Alternative to Accesskeys: http://www.wats.ca/articles/accesskeyalternatives/52 The Future of Accesskeys: http://www.wats.ca/articles/thefutureofaccesskeys/66 Perhaps after reviewing these, you may consider eliminating them entirely, making your quest a moot point. Cheers! JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
RE: [WSG] Spacing Issue
about the "evils" of old-school multi-nested table
layouts for about 3 years+ now, and you offer what? A table based
design with fixed fonts:
(extract from your source code: this is "standards" based design?)
The simple answer to your question is, don't do it the way you are doing
it. That may seem elitist to you, but to me, that just seems common
sense.
JF
--
John Foliot [EMAIL PROTECTED]
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
RE: [WSG] Newbie Questions: East-Asian Character Sets and Marking-up Poetry
Kwok Ting Lee wrote:
> This is, I guess, one of the first times I've written anything here,
> but I've run into a bit of a dilemma and was hoping for some advice:
>
> 1. I have a number of analyses of poems I am planning on posting to
> my weblog over the next few months, however, I'm a bit stumped as to
> what mark-up would be most semantically correct (The poems are quoted
> from another source, so for the time being I was thinking of using a
> blockquote):
>
> A.
> Title of Poem
>
> Blah...blah..blah...
> More blah.
>
>
>
>
> Or:
>
> B.
> Title of Poem
> Blah...blah..blach...
> More blah
> ...
>
>
Oh, no, definitely not the second option! Absolutely wrong use of the
definition list.
Perhaps:
Title of Poem
Blah...blah..blah...
More blah.
analyse of poem...
In other words, you separate your content from the original authors.
You may also want to include the cite attribute, as you indicate that
the source of the texts are from elsewhere:
http://www.other_source.com";>
Also, not sure about Chinese poetry, but I know western poetry often
requires specific line breaks, making it a candidate for ... (just
a random thought...)
Title of Poem
Blah...blah..blah...
More blah.....
analyse of poem...
Good Luck, HTH
JF
--
John Foliot [EMAIL PROTECTED]
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
RE: 'users with disabilities' WAS: [WSG] New front page for http: //ab c.net.au/
Conyers, Dwayne wrote: > Leslie Riggs wrote: > >> "Following web standards is all well and good, >> but how are you going to stream the audio when >> you can't hear it, if you can't do it this? >> How do you know your method will WORK?" > > Some people can be thick -- even when well-intentioned. > > But on the subject of streaming -- I find that very few streaming > broadcasts use captioning. Most television broadcasts have closed > captioning as mandatory and the ability to transmit text with radio > broadcasts is being used (although, more as an added feature). I > imagine the wild-west unregulated state of the web makes such > enforcement difficult at best. WCAG Priority 1: 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. 1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. 1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. FWIW, Captioning is relatively easy these days, even *if* different vendors use different implementations of SMIL. Of the 3 major methods/formats I've played with (QT, Real and Flash), Flash was the easiest, and given the widespread deployment of the plug-in probably the most "universal" of the three. If/when it comes to real-time however, all bets are off , as it still is somewhat labor intensive at the development end. > > I am sure there would be howls of protest if some licensing, such as > an FCC license for broadcasting, would be mandatory for the web -- and > perhaps there should be some "citizens band" version of the web (which > the spammers will overrun) and a "professional" version. Interesting > thought... > Please, no... JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Politically Correct Terminology (was RE: [WSG] New front page for http://abc.net.au/)
Nicola Rae wrote: > Hi, > > Just to chip in, I am writing a couple of articles for GAWDS (guild of > Accessible Web Designers) and have it on authority from them that the > correct terms to use are: > > "In the UK - instead of 'users with disabilities' - it should be > 'disabled users'. > > In the UK - instead of 'physical disabilities' - it should be > 'physical impairment'." > > As I also thought it was users with disabilities. > > Nikki > > For What it's Worth Dept About 3 years ago, I received permission to mirror the following "Words With Dignity" (http://wats.ca/resources/wordswithdignity/35), created by the Active Living Alliance, a NGO here in Canada (http://www.ala.ca/content/home.asp). So, not to be contrary to Nikki, it seems that it may also be a cultural thing, as the ALA suggest "Person(s) with a disability". Perhaps their final advice is most relevant: "Remember, appropriate terminology changes with the times. If in doubt, ask. Most people with a disability will be more than willing to help you." HTH JF -- John Foliot [EMAIL PROTECTED] Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
