Re: [WSG] minimal use of modernizr?
On Sat, May 12, 2012 at 9:54 AM, coder co...@gwelanmor-internet.co.uk wrote:
input name=email id=email placeholder=Enter your Email
Address
pattern=^[A-Za-z0-9](([_\.\-]?[a-zA-Z0-9]+)*)@([A-Za-z0-9]+)(([\.\-]?[a-zA-Z0-9]+)*)\.([A-Za-z]{2,})$
required type=email
Note that's not a safe regex to validate email addresses. It will
exclude legitimate addresses like john.doe+la...@gmail.com.
I suggest just keeping it simple and checking for ^.*@.*$.
See also discussion at:
http://www.regular-expressions.info/email.html
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] Expected behaviour of links to external websites
On Thu, Dec 29, 2011 at 3:25 PM, Hassan Schroeder has...@webtuitive.com wrote: On 12/28/11 8:08 AM, Benjamin Hawkes-Lewis wrote: [snip] Since they aren't navigating hypermedia, I'm not sure that's comparable. But typically you have a fine degree of user control of the opening of new windows in such programs. At the very least, it's predictable. Sorry, that's just nonsense. Take a non-technical-consumer app like Skype. On my Mac, it opens a single window when launched. Some functions change the content of that window; two open new windows. Which two functions? Feel free to predict, I'll wait :-) Point taken, I'm giving desktop apps too much credit here. FWIW Apple do provide guidance for how windows in OS X are supposed to work: http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Windows/Windows.html#//apple_ref/doc/uid/2961-TPXREF21 Not sure Skype is following that guidance … -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Expected behaviour of links to external websites
On Wed, Dec 28, 2011 at 9:39 AM, coder co...@gwelanmor-internet.co.uk wrote: What fascinates me (still) is that a PC (laptop, whatever) works by displaying many windows. Hell fire, the OS is called 'windows' . . . (unless you are a fruit fan). All the common programs employ 'several' windows to make their functionality easier to handle (just look at Dreamweaver or any other web design program of that ilk!) So, why do some folk think that's OK, but if you are using a browser it's awful? Strawman. Being able to open multiple browser windows is great! Having Joe Random Site Author decide when that should happen is not. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Expected behaviour of links to external websites
On Wed, Dec 28, 2011 at 12:49 PM, coder co...@gwelanmor-internet.co.uk wrote: SO you mean that mr Dreamweaver programmer, or Mr outlook, etc etc . . . shouldn't do it either? Since they aren't navigating hypermedia, I'm not sure that's comparable. But typically you have a fine degree of user control of the opening of new windows in such programs. At the very least, it's predictable. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Is it possible to style an attribute?
On Tue, Dec 20, 2011 at 4:38 AM, Grant Bailey
grant_malcolm_bai...@westnet.com.au wrote:
Hello,
I was wondering if anyone could clarify whether it is possible to style an
attribute. I realise this sounds odd, so allow me to explain what I wish to
do.
In my web page there are a number of terms that need to be defined. I like
the user to be able to hover over the term and get the definition that way.
For example:
dfn title=Made famous in the #8216;Star Trek#8217 TV
seriesteleportation/dfn
... produces
Made famous in the 'Star Trek' TV series
... when the user hovers over the defined term 'teleportation'.
I would prefer the words 'Star Trek' to appear in italics instead (yes, I am
fussy). Is there any way to do this?
While superficially attractive, @title is a problematic tool to use
for inline progressive disclosure of definitions because:
* It cannot store text structure (such as changes of voice or language).
* User agents do a terrible job of providing universal access to
information in @title. Popular user agents do not allow users to
access @title content using the keyboard (or a switch access device)
alone. Some user agents truncate long @title content. Popular screen
readers do not read @title on arbitrary elements - normally only on
abbr, acronym, img, and interactive controls like a, and then
depending on configuration.
In general, I'd strongly recommend putting your definitions in plain
view, along with anything else users might want to read:
dfnteleportation/dfn, made famous in the citeStar
Trek/cite TV series
Simple, robust, understood.
For lengthier definitions, ordinary hyperlinks to a glossary on the
same page or a definition on another page are a tried and tested,
universally familiar, universally accessible progressive disclosure
pattern:
a href=teleportation.htmlteleportation/a
a href=#glossary-teleportationteleportation/a
a href=glossary.html#teleportationteleportation/a
Any deviation from either plain view or simple hyperlinks is going to
introduce unnecessary barriers to consuming your content.
Still, we can think about ways to make your content harder to consume,
if you like. ;)
You could build on the hyperlinks approach by using JS to extract the
HTML in the #teleportation fragment and display it when the term is
hovered.
Alternatively, you could build on the plain view approach with
something more complicated such as:
span class=term-defined
tabindex=0dfnteleportation/dfnspan class=definition, made
famous in the citeStar Trek/cite TV series/span/span
/* Distinguish the defined term so that users have some sort of hint
it might be a control. At least this gives users of caret navigation
a chance. */
.term-defined dfn {
border: 1px solid red;
padding: 3px;
}
/* Hide offscreen left to be read by screen readers. */
.term-defined .definition {
left: -9px;
position: absolute;
}
/* Show the definition on keyboard focus or hover. */
.term-defined:focus .definition,
.term-defined:hover .definition {
position: static;
}
Leaving aside the usability issues raised by your question and
focusing purely on the technicalities, you can extract and style
content in attributes using CSS generated content, e.g.:
dfn:hover:before { content: attr(title); }
However, you can't apply transform punctuation within the raw text
content into italics with CSS alone, for that you'd need JS too.
Hope that helps.
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] media queries can't understand body tag
On Sun, Sep 18, 2011 at 4:34 PM, tee weblis...@gmail.com wrote:
Hmmm, media queries can't understand body tag; a id or class for the tag is
needed. Spec on W3C site doesn't indicate though as I see example like so:
@media all { body { background:lime } }
A browser bug?
Works for me in Chrome:
http://pastehtml.com/view/b7qe04of6.html
Do you have a testcase you can point to that fails in a named browser?
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] CSS variable navigational menu`
On Sun, Jan 9, 2011 at 2:09 PM, Goku San gokus...@hotmail.com wrote:
I have the following navigational menu bar. The menu has multiple parent
menu items.
[snip]
What currently happens is when a user hovers over
the Parent menu item, the child menu items appear below, horizontally, of
course. And each time, the child menu items appear to the far left. So the
problem is when we get to the 5th parent menu item, going across, hover over
it, the child menu items appear below towards the far left. So it
cosmetically looks wrong but also causes the user to further navigate their
mouse to get to the child items. Anyway to position the child menu items to
appear directly below the parents and not always to the far left?
Make the parents the containing blocks for the absolute positioning of
the children:
#nav .sub {
position: relative
}
http://reference.sitepoint.com/css/containingblock
I hope you'll ensure that users who are not using a mouse (e.g. people
with certain
motor disabilities) can still access the content linked in the child items,
whether via deeper links on hub pages reached via parent items or by ensuring
that child menus are focusable and visible on focus.
Food for thought:
http://www.w3.org/TR/WCAG20/#keyboard-operation
http://www.uie.com/articles/users_decide_first/
http://www.456bereastreet.com/archive/200705/accessible_expanding_and_collapsing_menu/
http://labs.benjaminhawkeslewis.com/rapid-access-hover-menu.html
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] how do I declare gradient and image in the background property?
On Fri, Dec 24, 2010 at 9:27 PM, tee weblis...@gmail.com wrote: background-image: -moz-linear-gradient(bottom, #57b0d7, #87C9EB); background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, #57b0d7),color-stop(1, #87C9EB)); One of the above lines will be discarded as an error in Gecko and WebKit. Which one is that? Gradient effect shows up fine in both Safari and Chrome. Trying to find the clue from Validator is not possible as it treated everything as error. background-image: url(../images/base_images/icon-ui.png) ; This line overwrites the previous value of background-image rather than setting background-image to be multiple images. http://www.w3.org/TR/css3-background/#layering http://www.w3.org/TR/css3-background/#the-background-image describes the comma-seperated syntax you want. OK, so I see, two images are possible in the background, but one for gradient and one for image is not possible especially no browser has native support for CSS3 gradient yet. Doesn't follow. moz-linear-gradient() and -webkit-gradient() are effectively alternate ways to declare an image and could be used wherever url() would be used in background-image. See also: http://dev.w3.org/csswg/css3-images/#gradients A gradient is an image that smoothly fades from one color to another. My point was merely: background-image: url(foo); background-image: url(bar); is equivalent to: background-image: url(bar); not background-image: url(foo), url(bar); -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] how do I declare gradient and image in the background property?
On Fri, Dec 24, 2010 at 2:02 AM, tee weblis...@gmail.com wrote: I want to add an icon : url(icon-ui.png) to the div but can't find a way to get it working. CSS3 allows two background images so I have the below which however disables the gradient in FF and webkit browsers. [snip] background-image: -moz-linear-gradient(bottom, #57b0d7, #87C9EB); background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, #57b0d7),color-stop(1, #87C9EB)); One of the above lines will be discarded as an error in Gecko and WebKit. background-image: url(../images/base_images/icon-ui.png) ; This line overwrites the previous value of background-image rather than setting background-image to be multiple images. http://www.w3.org/TR/css3-background/#layering http://www.w3.org/TR/css3-background/#the-background-image describes the comma-seperated syntax you want. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] disallow IE6 to load the main style sheet
On Sat, Dec 18, 2010 at 11:20 AM, tee weblis...@gmail.com wrote: I am finally to begin to stop supporting IE6 starts from 2011 as the usage has fallen below 5%. I don't want the IE6 users to see a broken page due to no special treatment made for the browser, rather, I would like them to see an un-styled page as if the style sheet has switch off. Can this be done? Yes. For example, you could: (1) Use conditional comments to exclude the IE6 (or earlier) engine: http://reference.sitepoint.com/css/conditionalcomments or (2) Use the HTTP User-Agent header to serve different markup to IE6. http://msdn.microsoft.com/en-us/library/ms537503(v=vs.85).aspx User-Agent headers are sometimes spoofed. On the other hand, they provide a more general mechanism that can be used to exclude styles/script from other old user agents (e.g. old Mozilla versions). Note that when doing sniffing of this sort, it is better to differentiate the experience for known-bad browsers and assume all other browsers are fully capable, so that users of capable minority browsers are not locked out or forced to spoof. In other words: use a blacklist not a whitelist. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Order of Tags within head (XHTML)
On Wed, Dec 15, 2010 at 9:53 AM, Foskett, Mike mike.fosk...@uk.tesco.com wrote: 8. The head section must not finish with a self closing element such as link. It may cause copy selection errors and Flash of un-styled content issues This is news to me. Does anyone have a citation or test case for this? -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Order of Tags within head (XHTML)
On Wed, Dec 15, 2010 at 11:03 AM, Foskett, Mike mike.fosk...@uk.tesco.com wrote: Referencing my own work seems pretty pointless but hey: http://www.websemantics.co.uk/resources/useful_css_snippets/ Not at all - thanks for the references. :) Headings: IE refuses to copy or highlight content text Right, in that case I have heard of this behavior for base: http://www.456bereastreet.com/archive/200608/base_elements_cause_text_selection_problems_in_ie/ base parsing in IE6 is very idiosyncratic: http://weblogs.asp.net/justin_rogers/pages/423843.aspx I think you'll find this problem doesn't apply to other self-closing elements, such as link. Un-styled content flashing up in IE. After reading, perhaps I could of worded the post a little better. I guess - isn't the second topic an argument for ending with a link as much as not? -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] lazyweb://schema.agnostic.URLs
On Wed, Nov 10, 2010 at 3:07 AM, Micky Hulse mickyhulse.li...@gmail.com wrote: I wonder how many folks don't specify the http: part? It sounds like there are no drawbacks. Not quite: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/ -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] XHTML or HTML?
On Wed, Nov 10, 2010 at 10:34 PM, cat soul cats...@thinkplan.org wrote: Any thoughts on which we ought to be using, To cut a _long_ story very short, if you have to ask this question, use HTML. See also: http://www.webdevout.net/articles/beware-of-xhtml http://dig.csail.mit.edu/breadcrumbs/node/166 http://wiki.whatwg.org/wiki/HTML_vs._XHTML and what information ought to be up at top of an HTML page, along with !DOCTYPE, etc? Typically, character encoding information (in case the user saves the page for offline consumption), page title, links to related resources (e.g. stylesheets for styling, feeds for feed autodiscovery), page description (often excerpted in search results pages). Possibly Open Graph Protocol metadata (http://opengraphprotocol.org/). -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] HTML5 - Marking up forms
On Wed, Nov 10, 2010 at 8:45 PM, Kevin Rapley ke...@digikev.co.uk wrote: I would be interested to gather your thoughts around this solution, using progress tags to mark progress through the form. A possible problem with this is that there is no guarantee that the user has completed earlier fields before moving on to later fields. I'd suggest adding a single progress element with JS, and tweaking its value as the user actually completes the form. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Getting my feet wet in HTML5
On 19 Aug 2010, at 11:08, Patrick H. Lauke wrote: http://www.w3.org/TR/html5/content-models.html#annotations-for-assistive-technology-products-aria However, with the new outline/sectioning algorithm, you can potentially go well over the classic h1-h6 number of heading levels, while the ARIA additional hints only allow mapping back to those six levels. Really? Maybe I'm missing something - what's non-conforming about: section h1 role=heading aria-level=7Foo/h1 /section given that [t]he value for 'aria-level' is an integer greater than or equal to 1. http://www.w3.org/WAI/PF/aria/complete#aria-level (Those ARIA annotations are strictly unnecessary when UAs implement the Strong native semantics and implied ARIA semantics from that table.) -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] link rel=stylesheet question
On 17 Jul 2010, at 17:42, Jody Tate wrote: In a stylesheet link, does the order of rel, href and type affect how a browser understands, loads, etc. a stylesheet? It doesn't. HTML attributes may appear in any order. http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.2 I usually see the rel attribute first, as in the example below, but does the order of attributes matter or is the order convention, convention meaning, that's what most people do? Convention. I guess it puts the /purpose/ of the linked resource (namely, being a stylesheet) first. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Flash video without embed tag
On 10 Jul 2010, at 16:35, Lesley Lutomski wrote: I understood that the object tag is supported by all major modern browsers, and the proprietary embed tag is not required, unless one needs to support very old browsers, which I don't. I have a Flash slideshow which a client wants included on a site. The automatically-generated code includes the embed tag and makes no provision for a static image in the absence of Flash. However, when I remove the embed section and add the static image, Firefox and Opera show the image, not the Flash slideshow. IE8, Safari and Chrome on Windows all display the Flash, as do Epiphany and Konqueror on Linux. Galeon, which is Gecko-based, displays the static image. I can't believe Firefox doesn't support the object tag, so I assume I've made an error in the code somewhere. While all the browsers you mention implement object (although implementation details vary significantly), it may well be that the automatically-generated code in question targets Firefox with the embed element rather than object. object classid=clsid:d27cdb6e-ae6d-11cf-96b8-44455354 codebase=http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0; width=500 height=462 id=CC1144627 align=middle param name=movie value=calasith.swf/ param name=quality value=high / param name=FlashVars value=xmlfile=calasith.xml/ param name=scale value=noscale / param name=salign value=lt / param name=bgcolor value=#ff / !--[if !IE]-- object type=application/x-shockwave-flash data=flash.swf width=800 height=600 !--![endif]-- img src=images/Cala_Sith.jpg width=400 height=300 alt=Cala Sith Guest House with view to the Oa / !--[if !IE]-- /object !--![endif]-- /object The outer object would only be loaded by Internet Explorer (it's set up to load the ActiveX Flash plugin). When that object fails to load, Firefox should try the inner object. But the inner object is not configured similarly to the outer object. In particular: 1. It's set to load a completely different Flash file (flash.swf not calasith.swf). I'm guessing flash.swf doesn't even exist. 2. It's not configured with a Flashvars param specifying an XML file. (Inner objects don't inherit outer object params). For a discussion of Flash loading strategies circa 2007 see: http://www.alistapart.com/articles/flashembedcagematch For a useful JS library that abstracts a lot of the browser differences see: http://code.google.com/p/swfobject/ Hope that helps. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] title attribute and semantic data
On Wed, Apr 28, 2010 at 6:07 PM, Dani Iswara daniisw...@gmail.com wrote: In some blog machines/engines/themes, title attribute usually has the same text as in anchor link. Eg. in post title with rel=bookmark. Redundant information, based on Web accessibility point of view. But http://www.w3.org/2003/12/semantic-extractor.html, Semantic Data Extractor tool built by W3C needs the title information for the bookmarkable points. So, is there a way to make it accessible and semantic properly? Short answer: omit redundant title attributes. The W3C hosts some formal standards endorsed by its membership (Recommendations). But they also host a load of tools and documents that have no special formal status. This tool is one of those. I think you are being misled by a bad user interface decision on the part of whomever built the tool. When the tool says [Unknown title], I suspect it is telling you that you have not added a title attribute to the link, not that you /must/ or even /should/ add a title to the link. If the developer *did* mean to tell you to add the attribute, then they were wrong and trumped both by your users' needs (which should always come first) and also by the formal Recommendations that tell you how to use the title attribute. The W3C HTML 4.01 Recommendation is clear: title provides advisory information about the element for which it is set: http://www.w3.org/TR/REC-html40/struct/global.html#adef-title If you don't have any useful advisory information to add, then title should be omitted or empty (title=''). In fact, because of the usability problems with common implementations of title, even if you do have useful advisory information, it may not be the best place to put it. http://www.paciellogroup.com/blog/?p=37 -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] validator error or my code?
On Mon, Mar 29, 2010 at 7:41 PM, tee weblis...@gmail.com wrote: I am giving the benefit of doubt that there might be a good reason. Hmm. There seems to a bit of confusion here. Not every document published by W3C is a Recommendation endorsed by W3C (an official standard). Examples of Recommendations include: * HTML 4.01: http://www.w3.org/TR/REC-html40/ * Web Content Accessibility Guidelines 2.0: http://www.w3.org/TR/WCAG20/ Examples of non-Recommendations include: * XHTML Media Types: http://www.w3.org/TR/xhtml-media-types/ * Techniques for WCAG 2.0: http://www.w3.org/TR/WCAG-TECHS/ Techniques for WCAG 2.0 are meant to be an unstandardized, evolving, technology-specific corpus of examples of how you might pass (standardized) technology-independent WCAG2 Success Criteria. The following are distinct (if overlapping) sets: * HTML4 validity * HTML4 conformance * WCAG2 conformance * Passing tests for chosen Techniques for WCAG 2.0 * Real-world accessibility For example, an individual document might (theoretically): * Validate and conform as HTML4, pass all the tests in all the WCAG2 Techniques, fail WCAG2 conformance, yet achieve real-world accessibility. * Flunk HTML4 validation and conformance and fail all the tests in all the WCAG2 Techniques but still achieve WCAG2 conformance and achieve real-world accessibility. Total Validator is checking your document for HTML SGML validity and against some snapshot of machine-testable tests from the WCAG2 Techniques corpus. You can check which by looking up the Error in their Error reference: http://www.totalvalidator.com/support/reference/index.html None of the distinct sets identified above necessarily require that labels and fields be descendants of form elements *or* any particular positioning of label elements relative to fields. But if you applying Technique H44 (Using label elements to associate text labels with form controls) then label elements must be: * before associated field elements that are select, textarea, or input of type text, file, or password * after associated field elements that are input of type radio or checkbox. How does this help real-world accessibility? The before/after distinction reflects a common convention in Graphical User Interfaces for positioning labels and fields: most labels go to the left of fields, but labels for checkboxes and radio buttons go to the right. Before label existed (it was introduced in HTML4), assistive technology such as screen readers had to infer what text labelled what control based on such GUI conventions. Continuing to follow those conventions allows such legacy software to continue to work. Modern assistive technology *should* correctly associate fields with labels regardless of label placement if there's a for/id association. But even with modern user agents, following those ancient GUI conventions helps accessibility because it helps make your interface immediately understandle to sighted users. This goes double if you are only poorly sighted and are viewing the page with zoom, or with your own preferred styles. See also the W3C discussions at: * http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JulSep/0716.html * http://lists.w3.org/Archives/Public/public-bpwg-access/2007Oct/0003.html * http://lists.w3.org/Archives/Public/w3c-wai-gl/1998OctDec/0009.html * http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0030.html * http://lists.w3.org/Archives/Public/w3c-wai-eo/1999AprJun/0168.html * http://lists.w3.org/Archives/Public/w3c-wai-eo/1999AprJun/0169.html As a tangent, tee mentioned the luxury to perform all sort of screen readers testing using pricy software. You cannot freely test with the free JAWS demo thanks to EULA restrictions, but the following are all free to test with: * Window-Eyes Demo (30-minutes-per-Windows-session limit) * NVDA on Windows (FOSS) * VoiceOver comes with OS X * Orca on GNOME (FOSS) The main hurdle here is not price, but developer inexperience with with complex assistive technology. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Fw: html vallidation
On 12/09/2009 06:46, Marvin Hunkin wrote: once i put a/p at the end of the last/a tag. i pass vallidation. now with this last file. in text pad. cannot seem to get it to vallidate. The error is straightforward. You have inserted a closing tag (/p) on line 76. If you backtrack through the document, you will find you have already closed the p element begun with an opening tag (p) on line 57 with a closing tag (/p) on line 72. So the validator correctly reports that it has found a closing tag for an element that is not open. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessible Forms
On 19/08/2009 20:04, David Dorward wrote: On 19 Aug 2009, at 19:35, Tom Livingston wrote: On a slightly related topic, I have wrapped inputs inside of labels for browser compatibility for the label clickability/focus issue (based on some research some time ago), but have just read for the first time recently, that this is not a good idea. Any thoughts? It isn't really a bad idea. It isn't as well supported as using the for attribute, so you should use that as well. Beyond that it is a matter of person taste. Well, I haven't personally verified this, but there are apparently some interoperability drawbacks to nesting inside labels even when you also use for and id, i.e. label for=name-field Name: input id=name-field name=name type=text /label See: http://green-beast.com/blog/?p=254 More generally, folks, see W3C's Web Accessibility Initiative's advice, which includes some reports about poor support for implicit labels: http://www.w3.org/TR/WCAG-TECHS/H44.html -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] table inside a dd?
On 17/08/2009 06:18, Tim MacKay wrote: I am marking up product nutritional information and am thinking of doing it like so: dl dt The Product /dt dd Paragraph blurb about the product /dd dd table …etcTabular data of the nutritional information/…etc /table /dd /dl Is nesting the table within the def list valid markup? Yes. I'd tend to suggest using headings (or headings inside a list) instead of a definition list, so that each product has an entry in the effective document outline: h2The Product/h2 pblurb/p table captionNutritional information/caption ... /table More practically, this allows non-mouse users of Opera (http://www.opera.com/browser/tutorials/nomouse/) or assistive technology (http://www.freedomscientific.com/Training/Surfs-up/Navigating.htm) to skip effectively from one product to another, and surfaces the products in assistive technology heading lists. Some assistive technology does have some support for definition lists, but it's not especially pretty, which isn't surprising given the HTML spec suggests using the element for terms and descriptions, and also for dialogs: http://www.webaim.org/discussion/mail_message.php?id=11226 -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessible websites
by comparison to me. I asked why you wouldn't describe publisher typeface and color suggestions as an 'offence' against user choice. I find it difficult to follow your answer, but it seems to be that they more rarely cause illegibility than font size suggestions? If I've got that right, this answer isn't very satisfying. Why is an instance of suggesting font size that does not produce illegibility for a particular user an offence against the user's choice when an instance of suggesting a color or typeface that does produce illegibility is not? I'm not saying face color are irrelevant WRT legibility. I understand that. Once you start down the road of saying a given publisher style suggestion is an offence against user choice, it's hard not to conclude that the only legitimate role for publisher styles would be layout hints for semantics that don't exist in (X)HTML (for example, alignment for table columns with different data types). I don't see that as a necessary result. /That/ is what I cannot understand about your position. You appear to be saying publisher body text font-size suggestions are bad because: 1. Overriding user choice is bad. 2. The default font size set in the browser constitutes a user choice for body text to use that font size. 3. Publisher body text font-size suggestions override default font size. Therefore: 4. Publisher font-size suggestions override a user choice. Therefore: 5. Publisher font-size suggestions are bad. While I think Premise 2 is erroneous, the argument doesn't change if you substitute color and typeface for font size. It looks logically inconsistent to make the argument in the case of font size but not color and typeface. How frequently font size suggestions cause legibility problems compared to color and typeface suggestions - and even on the evidence you presented color contrast is a common problem (a third of respondents complaining about it!) - is irrelevant to the principles at stake. How do you justify potentially reducing the legibility of content by overriding the colors and typefaces Joe Bloggs has chosen to leave at the defaults chosen by his browser manufacturer because they help him read, merely to satisfy your sense of aesthetics or because you think you know better about legibility for Joe than Joe and his browser vendor? -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessible websites
On 4/7/09 16:09, Felix Miata wrote: On 2009/07/04 10:13 (GMT+0100) Benjamin Hawkes-Lewis composed: On 2/7/09 17:07, Felix Miata wrote: Zoom, minimum text size and magnifiers are defense mechanisms. The basic problem is the pervasive offense - not respecting users' font size choices by incorporating them at 100% for the bulk of content. Thus, an even better way to address presbyopia is to design to make defenses unnecessary in the first place. I'm dubious about the rhetoric here: That you call it rhetoric doesn't make it so. Too small text is #1 user complaint: http://www.useit.com/alertbox/designmistakes.html That's not quite what the article says. Bad fonts was the biggest complaint from Nielsen's readers, but that category includes frozen font sizes and low contrast, not just small font sizes. W3 recommends 100%: http://www.w3.org/QA/Tips/font-size Recommends has a technical sense when it comes to W3C, and this isn't a formal recommendation: While the tips are carefully reviewed by the participants of the [Quality Assurance Interest] group, they should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications. As do others, e.g.: http://tobyinkster.co.uk/article/web-fonts/ http://www.xs4all.nl/~sbpoley/webmatters/fontsize.html http://informationarchitects.jp/100e2r/?v=4 http://fm.no-ip.com/auth/bigdefaults.html http://www.cameratim.com/personal/soapbox/morons-in-webspace#hard-to-read-fonts The claims I was trying to question were: Claim 1: Browser defaults always represent user choice. Claim 2: Acceptance of publisher font size suggestions is not a valid user choice. Claim 3: Publisher font size suggestions are an offence against user choice in some way that typeface and color suggestions are not. Most of the authorities you cite agree with Claim 1 but none offer any argument for Claims 1 or 2. Most contradict Claim 3. In Nielsen's survey of his readers, a third complained about poor color contrast. Oliver Reichenstein discusses how bad contrast can reduce legibility, and your own article says to be legible, text needs enough contrast. Toby Inkster and Stephen Poley both discuss how typeface choice can render text hard-to-read. Tim Seifert's excellent diatribe says [d]aft colour schemes are a pain and [s]etting a page to use particular fonts … can make a page difficult, or impossible to read. * Why should we treat browser default font size settings, which many users seem not to realise that they can change, Whether individuals know how [snip] is irrelevant Can you make a choice if you do not realize you have options? Of the users who do realize they can force font size but choose not to, why assume their choice is to use the default size with all designs rather than supplying a default size when publisher suggestions are absent? Why assume users are always trying to use that browser setting to do something it doesn't claim to do? You as designer aren't there, so you can't possibly know that what they have isn't acceptable or even perfect, much less improve their experience by deviating from the default. Both users and designers operate from a position of ignorance. Users who adjust their default font size don't know how their adjusted default font size will work with different colors and typefaces; designers know how common default font sizes will work with their suggested colors and typefaces, but not how the user's adjusted size will work. Because of these areas of ignorance, it is possible for designers to happen to suggest a more legible size. (The more users who don't adjust their default font size, the more likely this is.) Personal computers are not made by morons, but by humans who have preselected defaults designed to make the majority of users happy with most things just as they found them, ready to use as received. To think that an eagle-eyed web page designer biased by her giant tax-deductible worktool display can impose some other size in order to make things better for the majority is a preposterous supposition. I think the default styles used by popular browsers mainly aim at a mix of: 1. Making websites look similar to how they look in other popular browsers. 2. Making website controls look similar to those in the desktop widgets. They aren't designed from scratch to maximize usability by themselves or to maintain usability when combined with publisher styles. Maybe the original design decisions that underpinned these styles were good ones. (I don't buy the notion that default font sizes for body text are too big, at any rate.) It's certainly true that web designers often make bad design decisions, but it doesn't follow that their design decisions are invariably worse than the design decisions behind the basic styles. These styles come as a package. As soon as web designers start suggesting colors
Re: [WSG] Accessible websites
On 2/7/09 17:07, Felix Miata wrote: Zoom, minimum text size and magnifiers are defense mechanisms. The basic problem is the pervasive offense - not respecting users' font size choices by incorporating them at 100% for the bulk of content. Thus, an even better way to address presbyopia is to design to make defenses unnecessary in the first place. I'm dubious about the rhetoric here: * Why should we treat browser default font size settings, which many users seem not to realise that they can change, as users' font size choices? If users want to force a font size everywhere, they can and that is indisputably a user choice. * Why should we characterize user acceptance with reservations of publisher styles for the page, the web, or their entire system as a defensive measure? I think this language reinforces the popular (mis)conception that publisher styles are the natural presentation of the publisher's content, rather than a skin the user should be able to reject or use with modifications. Why not see this as a partnership rather than a battle? * Like font size, typeface and colors can radically affect the legibility of text and can be overridden by settings in popular browsers. Would you describe publisher typeface and color suggestions as an offence against user choice? If no, then why not? (As an aside, none of this undermines the clear usability advantages of designing for legibility when creating publisher skins.) I'd suggest that bigger problems in modern web design are the use of publisher styles that: 1. Prevent user acceptance of publisher styles with reservations. For example, use of background-image (which may need to be disabled for legibility reasons) to render headers and controls, with their text hidden, or positioned off-screen, or overlaid by another element where it won't be seen. I've railed against this, but I can't see this getting better until we develop a fast and reliable technique for detecting whether background-image will be applied with JS or CSS3's modifications to content are widely implemented: http://www.css3.info/image-replacement-in-css3/ 2. Far worse, prevent user rejection of publisher styles wholesale. For example, loading multiple application states (e.g. a form, its error messages and sucess messages) into the DOM simultaneously, then using the display property to determine which get shown to the user - rather than using DOM methods to add and remove fragments to the DOM as required. These do turn turn the partnership into a conflict. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] valid meta tags
On 26/5/09 18:39, designer wrote: Solved it! meta http-equiv=Content-Language content=EN/ should be meta name=language content=en / On the whole, this sounds more like a bug in the validator you're using. The first snippet is correct; the second snippet has no specification and no meaning to any consuming software AFAIK. meta name='language' certainly isn't among the techniques suggested by WAI (who instead suggest the lang attribute): http://www.w3.org/TR/WCAG10-HTML-TECHS/#identify-primary-lang http://www.w3.org/TR/WCAG20-TECHS/H57.html Nor is it among the techniques suggested for declaring a document's language by W3C's internationalization group: http://www.w3.org/TR/i18n-html-tech-lang/ If you want to indicate language to assistive technology, put lang and xml:lang attributes on your html element and any descendant elements where the language is different. This is known to work in actual screen readers like JAWS: http://developer.yahoo.net/blog/archives/2008/03/yahoo_search_re.html W3C suggests using meta http-equiv='content-language' in a subtly different way from the lang and xml:lang attributes: http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.101452727 http://www.w3.org/TR/i18n-html-tech-lang/#ri20040728.121358444 -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] valid meta tags
On 27/5/09 10:54, designer wrote: I'm using the one included with Chris Pederick's developer toolbar for Firefox (3), which is actually www.cynthiasays.com. It fails this: meta http-equiv=Content-Language content=EN/ but not this: meta name=language content=en / Try it for yourself. Is this validator at fault then? It's a testing assistant rather than a validator, strictly speaking. And yes, I'd say it's at fault in this case. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Possible to embed Flash w/out keyboard trap problems?
On 13/5/09 04:32, Rebecca Cox wrote: I'm wondering if its possible to embed Flash into HTML, using only HTML (no javascript) and for this to be keyboard accessible (HTML and Flash content usable by keyboard, no keyboard trap problems, for say A-grade list at http://developer.yahoo.com/yui/articles/gbs/) Test page: http://reb.net.nz/greed/index2.html Seems to be fine in IE, but in Firefox you cannot get keyboard focus onto the Flash without using the mouse. I suspect http://bugs.adobe.com/jira/browse/FP-1219 is why you can't move focus into the Flash without the keyboard. The more usual problem in Firefox is not being able to move focus /out/ of the Flash object. Just spotted http://blogs.adobe.com/accessibility/2009/04/firefox_focus_and_actual_links_1.html but this sounds as if it relies on the actionscript within the Flash itself being written in a particular way, and possibly on the javascript used to embed the flash into the HTML page. Interesting, hadn't seen that before. I'm not sure the technique is dependent on how you embed it, but it does look dependent on the JS DOM focus() method to move focus out of the Flash object. So I'd suggest the answer to your wondering is no. :( -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Image Replacement and Accessabilty
On 17/4/09 03:15, Russ Weakley wrote:
Of course, we'd all prefer to use the correct method, which is
display:none - but we have not been able to use this due to issues
with earlier versions of JAWS (content set to display: none was not
read aloud by these screen readers) - negatively affecting the very
people we were trying to assist. :(
Note, per the current CSS 2.1 spec, display is not a visual property
specifically, so it's probably not the correct method.
http://www.w3.org/TR/CSS21/visuren.html#display-prop :
display applies to all media types.
http://www.w3.org/TR/CSS21/aural.html#propdef-speak :
speak: none; Suppresses aural rendering so that the element requires
no time to render but descendants may override this value and will be
spoken. (To be sure to suppress rendering of an element and its
descendants, use the 'display' property).
That is to say, display might be more clearly named render (in
speech, in print, on screen, in braille, etc.).
If one assumed that screen readers should act as if they were aural or
braille browsers, then you could make a case that:
@media screen, projection {
.thing {
display: none;
}
}
would be a correct method. But this assumption doesn't really reflect
the actual approach taken by screen reader developers. All popular
screen readers ignore speech- and braille-specific CSS.
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] Image Replacement and Accessabilty
On 16/4/09 05:56, Gary Barber wrote:
Now it is
h#{
left: -px;
}
that had issues with screen readers.
Interesting. Not in my experience.
What screen readers and versions are you talking about? Do you have a
test case that demonstrates the problem?
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] Semantics: Microformats, RDFa
On 27/2/09 16:12, Andrew Maben wrote: There seem to be some Microformats proponents on the list, but I don't recall much mention of RDFa. I wonder if anyone has any thoughts on their relative merits, both immediately and in the longer term? It might be helpful if you described the problem you're hoping to solve with either, but anyway here are some thoughts under four headings. + Parser interoperability I don't have first-hand experience with implementing a parser, but I suspect how XHTML+RDFa should be parsed into RDF triples is better specified than how HTML4 and XHTML1 microformats should be parsed into data. The microformats community is still working on parsing specs, but the XHTML+RDFa standard includes parsing specs: http://www.w3.org/TR/rdfa-syntax/#s_rdfaindetail http://microformats.org/wiki/parsing + HTML compatibility You are supposed to be able to express microformats in conforming HTML 4.01 as well as XHTML 1.x. This has been partially achieved in the sense that no microformat requires you to write HTML 4.01 that does not meet its SGML validity requirements, though some accepted microformat patterns do (arguably, at least) abuse HTML4 elements and attributes. By contrast, RDFa has only been specified for XHTML. However, Internet Explorer - the most popular browser - does not support XHTML. The guidance for how authors should serve XHTML family documents as text/html is still being written (by the XHTML 2 WG): http://www.w3.org/MarkUp/Drafts/#xhtml-media-types Worse, there is no standard yet for how RDFa should be treated when served as text/html rather than XML. This will be defined by the HTML WG/WHATWG, who are working on the next version of the HTML standard and are currently unpersuaded of the need to support RDFa: http://www.w3.org/html/wg/ http://www.whatwg.org/ http://tinyurl.com/bbx75q [public-h...@w3.org archives] http://tinyurl.com/akjzm3 [wha...@whatwg.org archives] + Accessibility Microformats create minor accessibility problems when you need to include machine-parseable data that is equivalent or supplementary to human-friendly visible information. The microformats community is still working on better approaches to including such information. http://www.webstandards.org/2007/04/27/haccessibility/ http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml http://microformats.org/wiki/machine-data RDFa does not create the same problems, because it adds extension points for this purpose (the content attribute on every element, primarily). http://www.w3.org/TR/rdfa-syntax/#rdfa-attributes + Distributed extensibility You can unilaterally make up your own vocabulary in RDFa, but not microformats, which must be developed and standardized through the microformats community process. (Of course, you can make up markup patterns that can be used to extract metadata - but those aren't official microformats.) Whether this is good or bad perhaps depends on how widely useful your vocabulary would be. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility testing
On 11/2/09 05:59, Henrik Madsen wrote: What similar software / online systems do people use and get reliable results (if reliable results are indeed attainable)? Define reliable results. :) Such systems are intrinsically limited in what they can test. If your contract requires you to pass checks with this piece of software, fine, but beyond that I recommend using wetware as well as software: imagining about the user experience for different user groups [1-2], thinking through the application of accessibility guidelines to your site [3-5], code reviewing your code line-by-line with fellow developers, and if at all possible testing the final product with people with disabilities [6-7]. [1] http://www.uiaccess.com/accessucd/ [2] http://delicious.com/benjaminhawkeslewis/howPeopleWithDisabilitiesUseTheWeb?sort=alphaorder=asc [3] http://www.section508.gov/ [4] http://www.w3.org/TR/WCAG10/ [5] http://www.w3.org/WAI/intro/wcag.php [6] http://dev.opera.com/articles/view/26-accessibility-testing/#usertesting [7] http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_seeitrightaudit.hcsp -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Implication of empty divs
On 9/2/09 07:45, Chris F.A. Johnson wrote: How can CSS overflow replace div style=clear:both;/div? See http://www.ejeliot.com/blog/59 -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Implication of empty divs
On 9/2/09 02:44, Gerard Hynes (Gmail) wrote: I'm not expert about screen readers, but I did run a site I upgraded through JAWS with some interesting results. The site had alot of pnbsp;/p due to the CMS they were using and JAWS would translate this to/speak out blank which wasn't ideal. Am not sure if it would do the same forp/p ordiv/div ordiv /. Precise behavior will vary with publisher styling of the DOM, platform, browser (and version), screen reader (and version), user configuration, and the commands used when reading that part of the page. For example, JAWS 10 has a concept of blank lines. It will read out blank as you step through a document if you come to something that matches that concept. The following variations: pbar/p pbaz/p p style=margin: 0;padding: 0;bar/p p style=margin: 0;padding: 0;baz/p pbar/p pnbsp;/p pnbsp;/p pbaz/p pbar/p div/div pbaz/p pbar/p div/div div/div pbaz/p are _all_ read: bar blank baz It also has a configuration setting for whether blank lines should be spoken with the Say All command. If this is off (as it is by default), then the above variations would all be read: bar baz -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Implication of empty divs
On 8/2/09 23:33, Ben Lau wrote: Are there any (seriously) bad implications of having empty DIVs around your HTML document? I try to avoid using them personally, but there are cases where the visual design has forced me to add empty divs (or spans) just to achieve the look. Apart from adding extra weight and cluttering the document, I understand screen readers do not pick up divs and spans? The short answer is that at most they would treat an empty div or span as a blank line or space. I wouldn't worry about it. The long answer is that it is possible to overload div and span elements with content and functionality in other ways that might get picked up by screen readers (using ARIA), but that's not the scenario you're describing. Would I be better off to insert these meaningless decorative tags using javascript and modifying the DOM, while non-javascript users would see a more cut down version of the design? As far as I can see, you would not be helping non-JS users by doing so. Do screen readers pick up javascript and events? Popular screen readers are not web browsers themselves. Instead, they are system-wide services that provide an aural and/or braille output and keyboard input interface to the desktop environment and applications like office software, media players, and (most importantly, for your purposes) popular web browsers. See links at: http://delicious.com/benjaminhawkeslewis/howScreenReadersWork Popular web browsers, of course, can pick up on JavaScript and events. But DHTML communication to screen readers users can break down on various levels. For example: 1. Failure to bind functionality to standard UI controls like buttons, hyperlinks, and form controls might lead to screen readers users being unaware that functionality is available or unable to activate such functionality. 2. Scripted changes to the page might not be picked up by the screen reader. Screen readers often work with a sort of snapshot of the structure and content of the web document (a virtual buffer). Sometimes this snapshot is not updated when the real document is altered by script. 3. The user might not be alerted to changes to the page or snapshot. 4. The user might be constantly interrupted by irrelevant changes. For further reading see: http://delicious.com/benjaminhawkeslewis/accessibility+ajax And for accessibility best practices generally see: http://www.w3.org/WAI/intro/wcag.php http://www.rnib.org.uk/xpedio/groups/public/documents/code/public_wacsitemap.hcsp Hope that helps. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
On 3/2/09 20:13, Brett Patterson wrote:
I really don't understand what you mean, when you say:
It's a designer-bug. Vertical position of the navigation relies entirely
on font size, which means it is all over the place in my browsers on
first load.
No two browsers calculate font size exactly the same before rendering,
so relying on pixel-perfect font size across browser-land is not a
good idea. Add in font resizing and other regular options in browsers,
and it gets a lot worse - for the whole layout.
The problem should not rely on font size, but rather the margin from the
top of the item that margin-top is being applied to, to the bottom of
the item that is directly above the item that margin-top is being
applied to, correct?
I think Gunlaug is referring to this (simplified):
div id=hdr
img alt=Text equivalent src=logo.gif /
div id=pageheader
Title here
div id=tabs
Tabs here
/div
/div
/div
#hdr {
border-bottom: 1px solid #CC9966;
height: 90px;
}
#pageheader {
float: left;
}
You've floated #pageheader out of the normal flow that determines the
height of #hdr, and there's nothing in place to force #hdr to contain
the lowest floated descendant. The logo image is in normal flow but it
is 85px tall, so what determines the height of #hdr is the height:
90px; setting.
Consequently, the alignment of the bottom of #tabs with the bottom
border #hdr depends on #pageheader actually being 90px tall. Since it's
got text inside it, and you can suggest but cannot expect a font height
(and therefore cannot even make a reliable prediction about how many
lines a given string will need), that dependency is brittle in the
extreme. In Firefox 3's Zoom submenu (under the View menu) try ticking
Zoom Text Only and then zooming in twice to watch it break horribly,
with the title text wrapping to the next line forcing the tabs entirely
below the border.
For further reading see:
* http://www.w3.org/TR/CSS21/visudet.html#the-height-property
* http://www.w3.org/TR/CSS21/visudet.html#Computing_heights_and_margins
* http://www.ejeliot.com/blog/59
I mean I do know that font size across browsers does not render the
same, but if using pixels for a font size, should the pixels (in
relation to size) render the same?
I'm not entirely sure I understand the question (in relation to size -
size of what?).
The size of a CSS pixel is intended to be relative to the resolution of
the viewport, and is ultimately up to the user agent:
Pixel units are relative to the resolution of the viewing device, i.e.,
most often a computer display. If the pixel density of the output device
is very different from that of a typical computer display, the user
agent should rescale pixel values. It is recommended that the reference
pixel be the visual angle of one pixel on a device with a pixel density
of 96dpi and a distance from the reader of an arm's length. For a
nominal arm's length of 28 inches, the visual angle is therefore about
0.0213 degrees.
http://www.w3.org/TR/CSS21/syndata.html#length-units
Most desktop browsers make a CSS pixel a monitor pixel, however most
desktop browsers (Opera, IE7, IE8, Firefox 3) also include a zoom
function that changes the effective pixel size up or down. Note that
some zoom functions (Opera, IE8) include fit-to-width reflowing
capabilities that mean that there's no guarantee that a box width in px
will remain proportional to a font height specified in px.
Most desktop browsers (IE, Firefox, Safari) allow users to adjust the
font size up or down in steps. In IE's case, these adjustments do not
affect font sizes specified in pixels.
In addition, most desktop browsers (IE, Opera, Firefox, Safari) enforce
minimum font sizes in real pixels and allow users to change them, and
allow users to disregard publisher suggestions about font size and set
enforce their own preferences.
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] How to hide/show form questions with javascript while meeting WCAG 2?
On 27/1/09 05:19, littler...@internode.on.net wrote: I am starting to learn javascript/jquery and would like to use it to hide questions on a form dependant on the answer to another question. Hmm. Can we explore the precise interaction a little bit more before jumping to solutions? How will the same transaction be handled when JavaScript is unavailable, if at all? If a user was to see all the questions all the time, would they still understand the form? If not, would they understand the form if the wording of the questions was altered a bit? I have seen plenty of working examples but am concerned that they wouldn't be accessible or comply with WCAG 2.0. Does anyone have an example of best practice or can advise on how they deal with this issue? There are three basic approaches to hiding and showing things that you should choose between based on the core WCAG principles (perceptibility, understandability, operability, robustness): 1. DOM mutation: remove elements from the DOM (removeChild, or innerHTML), store them in a variable, and then add them again later (appendChild/insertBefore, or innerHTML). In theory, this should hide things from all users. It's the most appropriate approach when the document would be nonsensical if the elements continued to be shown to the user. 2. display method: suggest that the elements are styled with display: none;. In theory, this should hide things from any user from any users that are using user agents that support CSS (not all do), that are not rejecting publisher styles (some do), and that are not overriding that style. This is the most appropriate approach when the document would be understandable even if the elements continued to be shown to the user, but hiding them simplifies or prettifies the content. 3. Off-screen method: Suggest that the elements are styled so as to be positioned off-screen (e.g. left: -9px; position: absolute;). In theory this should hide things from any sighted users that are using user agents that support CSS (not all do), that are not rejecting publisher styles (some do), and that are not overriding that style. This is the most appropriate approach when the document would be understandable if the elements continued to be shown to the user, and hiding them from sighted users applying CSS simplifies or prettifies the content for those users, but the content must be shown to any group of users who are visually impaired or whose user agent or configuration does not apply that CSS. A gotcha with techniques 1 and 2 is that assistive technology may not refresh its buffer or cache of the DOM immediately and so may not reflect your dynamic changes when representing your content to the end-user. Testing is crucial here. See also: http://juicystudio.com/article/making-ajax-work-with-screen-readers.php http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php http://www.gwmicro.com/blog/index.php/all/?title=regarding_web_based_dynamic_contentmore=1c=1tb=1pb=1 http://wiki.codetalks.org/wiki/index.php/How_to_use_ARIA_Live_Regions_for_dynamic_content http://www.paciellogroup.com/blog/?p=65 A gotcha with techniques 2 and 3 is that you must ensure that if a hidden element receives keyboard focus (whether by pressing an accesskey, or moving through the tab order, or jumping to an element of a particular type, or being sent there dynamically), either focus must be automatically passed on to a visible element or the element must be made visible. (focus, blur, DOMFocusIn DOMFocusOut, focusin, and focusout UI events and :focus and :active pseudo-classes are the key tools at your disposals here.) Otherwise, the keyboard focus indicator will be hidden. That would be confusing to sighted keyboard users and a WCAG2 violation: http://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-visible Most JavaScript for hiding and showing content actually uses the display method, because it's easy, even when it's arguably inappropriate. A frequent mistake of this sort is to send the client an HTML form with error messages embedded directly in the HTML and styled with display: none;, which are then styled display: block if a field fails form validation. This breaks horribly when your styling suggestions aren't applied, because the user will be confused by error messages that do not reflect actual input. Hope that helps. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Validating (X)HTML + ARIA
On 20/1/09 23:13, Anthony Ziebell wrote: because an implementation of ARIA without using JavaScript to do so would essentially mean a drop of support of legacy browsers If all you are doing is adding some unrecognized ARIA attributes to _existing_ HTML or XHTML content, then such attributes are (realistically) not going to harm users of legacy browsers. Some aspects of ARIA (such as tabindex for all elements and negative values of tabindex) were implemented in some older browsers, even though invalid in HTML 4.x and XHTML 1.x, long before ARIA was proposed. In so far as new assistive technology performs any DOM inspections for ARIA attributes in legacy browsers (probably not much), the presence of ARIA attributes might help users of those combinations. So long as you continue to use the same HTML 4.01 or XHTML 1.x elements to mark up the same content, I don't understand why the additional inclusion of ARIA attributes (say, landmark roles) should make any difference to support of legacy browsers. For example, if you enhanced a document with you a Skip to main content link by additionally marking up your navigation area with role=navigation and your main content area with role=main, the net effect of adding ARIA attributes on backwards compatibility could be positive. I can see a conflict with backwards compatibility if you let the presence of ARIA attributes change how you author your content. For example, if you _replaced_ a Skip to main content link by marking up your navigation area with role=navigation and your main content area with role=main, you'd be replacing a technique that works for a given set of older user agent software with a technique that works for a given set of newer user agent software. In that scenario, the net effect of adding ARIA attributes on backwards compatibility could be negative. Similarly, if you depended on ARIA to communicate semantics available in existing (X)HTML (say replacing h2 with div role='heading' aria-level='2') or if you introduce new semantics/functionality communicable with ARIA but not existing (X)HTML are essential to understanding/using your content rather than an enhancement , you'd lose backwards compatibility for your content. So as you can see, progressively enhancing with ARIA doesn't equate to adding ARIA attributes with JavaScript, but rather to using ARIA as an enhancement rather than replacement whether dependent on JS or not. I think the more serious compatibility problem with ARIA is the immaturity and rapid pace of change of the draft specifications and implementations. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Validating (X)HTML + ARIA
On 20/1/09 06:24, Anthony Ziebell wrote: Is it true XHTML 1.1 supports modularization and thus, ARIA, except for the role attribute / values? I'm not sure I understand the question. Modularization, in XHTML's case, refers to the splitting of XHTML itself into modules. This allows the definition of profiles of XHTML by adding modules together or the definition of compound XHTML family schema that mix a selection of XHTML modules with elements, attributes, and entities from other namespaces. See: http://www.w3.org/TR/1999/WD-html-in-xml-19990224/#mods http://www.w3.org/TR/xhtml-modularization/introduction.html#s_intro_whatismod XHTML 1.1 is a profile of XHTML defined by adding XHTML modules together. A strictly conforming XHTML 1.1 document cannot include ARIA attributes: http://www.w3.org/TR/2001/REC-xhtml11-20010531/conformance.html#strict http://www.w3.org/TR/xhtml11/conformance.html#docconf Modularization doesn't mean much either way for ARIA usage, since: 1. If you wanted to mix ARIA and XHTML in an XHTML family schema, all modularization would allow you to do is ban existing bits of XHTML (say, presentational elements) from that schema. 2. If you just want to mix ARIA and XHTML in an XML document, you don't need an XHTML family schema - especially if you want to use XHTML 1.1's profile wholesale. XHTML 1.1 (latest draft) allows XHTML 1.1 to be served as text/html as defined in RFC2854 or application/xhtml+xml as defined in RFC3236. The first edition of XHTML 1.1 doesn't mention media types: http://www.w3.org/TR/2001/REC-xhtml11-20010531/ The latest public draft of the second edition (February 2007) says: XHTML 1.1 documents SHOULD be labeled with the Internet Media Type text/html as defined in [RFC2854] or application/xhtml+xml as defined in [RFC3236]. The latest editor's draft (January 2009) says: XHTML 1.1 documents SHOULD be labeled with the Internet Media Type application/xhtml+xml as defined in [RFC3236] http://www.w3.org/MarkUp/2009/ED-xhtml11-20090106/conformance.html#strict Note that SHOULD has a specific meaning defined in RFC 2119: http://www.ietf.org/rfc/rfc2119.txt . Both the drafts refer us to W3C's note on XHTML media types: http://www.w3.org/TR/xhtml-media-types/ Which has no normative status, but was a summary of the HTML Working Group's view of best practice in 2002, and says XHTML 1.1 SHOULD NOT be served as text/html, MAY be served as application/xml or text/xml, and SHOULD be served as application/xhtml+xml. (Again, these are RFC 2119 terms). But this note is itself being revised by the XHTML 2 Working Group: http://www.w3.org/MarkUp/2009/ED-xhtml-media-types-20090116/ It is still a note with no normative status, and this time should etc. are not defined with reference to RFC 2119. The note suggests best practices for serving XHTML documents as text/html: * They should conform to a set of guidelines, ultimately a reworking of the guidelines at the end of XHTML 1.0 * They should not be XHTML Family documents that mix XHTML with features from other namespaces (e.g. SVG, MathML, YourMadeUpML). What rather confuses all this is that there is _another_ W3C Working Group that is simultaneously defining how text/html and XML features in the XHTML namespace ( http://www.w3.org/1999/xhtml/ ) should actually be processed, the new HTML WG: http://www.w3.org/html/wg/ This is exciting as it looks like we are so close to being able to implement websites which have a much higher level of accessibility. If you think a major barrier to ARIA adoption is that there is no way to use ARIA in your document and conform to a W3C Standard, then discussions around including ARIA in HTML5, the drafting of XHTML 1.2 (which includes ARIA), and the gradual standardization of ARIA itself are of significantly more interest than any draft of XHTML 1.1. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
On 20/1/09 08:31, Michael MD wrote: If something like February 9th appears on a page is that really human-friendly? . what year is that? is it coming up ? ... or am I looking at an old page about something from last year? ... Um... depends, look at the surrounding text in this test case: http://microformats.org/wiki/value-excerption-value-title-test#hCard.231:_An_hCard_bday it's a birthday, so last year, this year, and every year thereafter. ;) It would certainly be nice if people were to learn to write human dates more clearly! I agree with this general point, though the way to write dates most clearly in English is 9 February 2009 (or, somewhat worse, February 9th 2009) not any machine-readable readable syntax. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Validating (X)HTML + ARIA
On 20/1/09 22:47, Anthony Ziebell wrote: It's more of a business decision... do we enhance our sites and make them a whole lot more accessible, meanwhile dropping support for older browsers? Other than an accessibility technology inspecting the DOM for ARIA attributes, what makes you think that the presence or absence of ARIA attributes in particular makes any (real world) difference to compatibility if the user is using a browser that does not implement any functionality for those attributes other than inserting them into the DOM? Surely what makes the big difference to accessibility for users of older user agents is the absence of an accessibility infrastructure for certain DHTML widgets and behaviours that works in those user agents? Or do we sit and wait until older browsers no longer have a market share and leave our visually impaired visitors in the dark? Someone mentioned using JavaScript to implement ARIA parameters. This is a good idea... Why? but just how accessible would that be to a vision impaired visitor with JavaScript turned off? As accessible as your page normally is with JavaScript turned off to the same user. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Website review : http://webprocafe.com
On 16/1/09 16:41, Stewart Griffiths wrote: Please can you provide feedback on the following website http://webprocafe.com/ We are looking for thoughts on the design and usability of the site, plus any general feedback you want to provide. Hmm. Just looked at the homepage. Pointless XHTML formedness errors, lack of heading elements, table layouts, presentational markup, inline styles, obtrusive JavaScript, unnecessary browser detection, presentational class names, and a layout that begins to break with only two text size steps up (at least in Safari) may be byproducts of vBulletin but they undercut the site's ostensible purpose of discussing professional web development in a way that I find hard to overlook given you've adopted a self-hosted solution for the forum. More subjectively, I think the random bits of sans-serif (menu links at the side and some of the menu links at the top) look discordant, the lack of contrast between the brown backgrounds and darker brown text may make the content hard to read for some users (I'd suggesting using coffee text on white instead of brown text on brown), and the icons in the left-hand navigation menu look too randomly generic. Sorry that's harsh, but I hope it helps. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] SEO and Flash
On 15/1/09 06:59, Stuart Foulstone wrote: If the text in Flash is accessible SEs will index it. Search robots are in effect blind readers. If text in Flash is accessible, screen readers can read it. The mechanisms provided for search engines and screen readers to read Flash content are very different, not least because screen readers need to interact with Flash functionality not just read Flash content. However, sensible screen-reader users disable Flash. Not when they want to listen to videos and audio on the web, they don't. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Frames/iFrames [SEC=UNCLASSIFIED]
On 14/1/09 05:31, mary-anne.nay...@medicareaustralia.gov.au wrote: They are using them to facilitate the menu/header/footer ite,s across a host of applications which sit on a range of differing servers using a rang of differing technologies. I suggested SSI's but that is not possible due to server configuration issues. I think I am going to allow iFrames but with some stipulations. My company uses IFRAME elements to share headers and footers with partner sites. The biggest problem with this approach is that you have to specify a HEIGHT attribute for the IFRAME. That forces you to make assumptions about the height of the IFRAME content, and those assumptions will inevitably break down under some conditions. (Try bumping up your text size three or four steps and see what happens!) -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Frames/iFrames [SEC=UNCLASSIFIED]
On 12/1/09 07:12, mary-anne.nay...@medicareaustralia.gov.au wrote: I am just wondering what is the general consensus on the use of Frames or iFrames these days. WCAG2.0 is not terribly clear on whether we should or shouldn't be using them. WCAG 2.0 tries to express the principles of web accessibility in a technology independent manner. If you can use frames in consistency with those principles, that's compatible with conforming to WCAG 2.0. Note that the Techniques document for WCAG 2.0 does include some HTML techniques relevant to frames: http://www.w3.org/TR/WCAG20-TECHS/H64.html http://www.w3.org/TR/WCAG20-TECHS/H70.html I understand there are usability issues as well as problems with Search Engines. The usability minefield with frames described at - http://www.useit.com/alertbox/9612.html - hasn't disappeared. The interoperability problem hasn't disappeared either. There are still browsers in use - some mobile browsers, Lynx - that can't handle frames. More recently, security-conscious users are being advised to disable iframe support as one measure against clickjacking: http://hackademix.net/2008/09/27/clickjacking-and-noscript http://hackademix.net/2008/09/29/clickjacking-and-other-browsers-ie-safari-chrome-opera/ http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/ Likewise the problems with frames for search engines described at the article Nielsen cites: http://www.ehsco.com/opinion/19980209.html appear to still exist today: http://www.google.com/support/webmasters/bin/answer.py?hl=enanswer=35769 http://www.google.com/support/webmasters/bin/answer.py?hl=enanswer=34445 http://searchenginewatch.com/2167901 http://help.yahoo.com/l/us/yahoo/search/webcrawler/slurp-08.html?terms=frames (although contrast http://help.yahoo.com/l/us/yahoo/search/webcrawler/slurp-09.html?terms=frames ) I have a client that seems determined to use them despite my best advice. Use them how for what? -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Title attribute
On 12/1/09 00:00, Jens-Uwe Korff wrote: I found that, contrary to what I believed previously, this is not required for assistive technologies, ie. screenreaders. They usually pick up the anchor text well. http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/ is a very useful discussion of the TITLE attribute from an accessibility perspective. I think the destination of a link is best made clear by the link text. TITLE attributes are useful to provide tooltip text for icons however. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] credibility of accessibility validator and evaluator
On 31/12/08 10:43, tee wrote: I was testing the FAE the first time, and is questioning its report credibility because it fails my document title 50%. Not that I don't like to be wrong :) According to the report: Document Title Best Practices * The page should contain exactly one title element. * Pass: 1 title element was found. * The text content of each h1 element should match all or part of the title content. * Fail: 0% (0 out of 1) I cannot find any information about h1 content should match part or all of the title content on WCAG 2.0 guideline. There isn't guideline reference link to WCAG 2.0 official site, and I couldn't find such info on WCAG official document. FAE isn't a WCAG 2.0 compliance tool. It's a tool testing for compliance with a set of best practices (CITES/DRES Best Practices) that aim to create accessible websites that comply with WCAG and Section 508 compliance. http://fae.cita.uiuc.edu/about.php?page=overview It therefore sbouldn't surprise you if: 1. Some tests aim at accessibility without being directly attributable to WCAG or Section 508. 2. Other tests depend on interpretation of WCAG or Section 508. Note, furthermore, that the version of WCAG in question is 1.0 not 2.0: http://cita.disability.uiuc.edu/html-best-practices/ The set of rules about titles refers back to WCAG 1.0 3.5 (Use header elements to convey document structure and use them according to specification.) and WCAG 1.0 13.8 (Place distinguishing information at the beginning of headings, paragraphs, lists, etc): http://cita.disability.uiuc.edu/html-best-practices/reqs.php (Note because W3C has changed what http://www.w3.org/TR/WCAG/ points to, all their reference URLs are broken.) So here TITLE is being used to distinguish the page with its page title and the site with its site title, and H1 is being used to structure the page under that page title. If you have good reason to believe this would harm your users, don't do it! For my part, I think this particular piece of advice is generally sensible from a usability perspective. Though from the SEO point of view, this 'advice' makes sense. Although it's not terrible from an SEO point of view, it's not necessarily optimal either. This also makes me wonder how reliable those accessibility validators are because I get different results from Cynthia Says and Total Validators-these are the two I frequently use. Those are likely using completely different rulesets again, so you have every reason to expect them to be different. They are as reliable as their rulesets. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] NCFH Site Check and CSS Issues
On 27/12/08 17:36, Chris Kennon wrote: (3) The use of a background-image for the logo with the text positioned off-screen means that if the user enforces their own colors for increased legibility, the header _and its text_ will likely be invisible. What image replacement techniques do you suggest to compensate for this issue? Since all the widely CSS image replacement hacks I've seen are broken in this regard, I suggest using IMG with ALT as the least bad option until CSS3 content:url() image replacement is implemented in browsers additional to the (uncommonly used) Opera and Safari. http://www.w3.org/TR/css3-content/ http://www.css3.info/image-replacement-in-css3/ -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] NCFH Site Check and CSS Issues
On 22/12/08 20:55, Chris Kennon wrote: Here a screen capture of the desired site layout and navigation styles: http://working.bushidodeep.com/dwd/ncfh/02/desired.png The drop downs appear above a flash element. And some reports of the background color not appearing Firefox have been reported. Would the list review the site, offering CSS suggestions as needed? http://working.bushidodeep.com/dwd/ncfh/02/ncfh_template.html Like Henrik, I'm curious as to why a Flash object is being used, not a background image. I suspect the drop downs aren't appearing above the Flash properly because its wmode is set to transparent not opaque. http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_15523 A few other issues: (1) What's your plan for keyboard accessibility of the navigation (or the items the navigation leads to)? At the moment, as I tab through the page, for large swathes of the tab order there is almost no visible focus. http://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-visible http://www.w3.org/TR/WCAG20/#keyboard-operation Make sure there's a visible focus ring. (2) In your CSS, ul#mainNav a sets a height in pixels for an anchor. This is highly unrealistic in a medium where you don't have good control over the font size. It causes the navigation items to overlap with font size increased merely two steps in Firefox. (3) The use of a background-image for the logo with the text positioned off-screen means that if the user enforces their own colors for increased legibility, the header _and its text_ will likely be invisible. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] PopDown Menu NCFH
Chris Kennon wrote: It's been a while, but given the season, not only could I use the wisdom of the list, but the subject matter of the project begs a collaborative effort. The National Center on Family Homeless redesign requires drop-down menus, of which I'm not a fan, but are required. Would those experienced with Pure CSS Drop-Downs assist my effort? Why does the design require Pure CSS drop downs? Is there a plan for keyboard accessibility here? Note the famous Pure CSS dropdowns tend to require JS anyway in IE6 to fake :hover support. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Dropmenu accessibility and layout problem IE6
Al Sparber wrote: Having a hierarchical menu operate via the keyboard is, in my opinion, not the most accessible approach. This simple example page might provide some insight into how to apprach the accessibility of a dropdown or flyout menu: http://www.projectseven.com/products/menusystems/pmm2/ug-examples/accessible/ Multiple hubpages reached are an excellent fallback for the non-JS state, and I'd agree that using multiple hubs is a reasonable keyboard-accessible alternative for dropdowns, particular as opposed to having lots of options in the tab order. However: * Opening submenus by activating a button-type control (e.g. pressing enter) avoids the need for excess tabbing. (Assuming your submenu links aren't tabbable when submenus are closed.) * I'm a bit uncomfortable with indicating to the keyboard user that a menu will dropdown with an arrow (as in your example), but sending them to another page instead. A possible enhancement might be making the arrow appear on mouse hover only? On the whole, I favour multiple hubpages over dropdown menus as a navigation pattern for typical content-driven websites as opposed to web applications - they keep options simple and visible. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] the Name attribute
Joe Ortenzi wrote: standards compliance should not be confused with WCAG conformance. HTML is a standard WCAG is a guidance that people use as if it were a standard, which could easily be a standard but is effectively not one. However, complying with WCAG confers added benefits which standards compliance creators strive for. Standard is a pretty fuzzy word. Might be worth clarifying what definition of standard you are applying here. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HTML/XHTML/XML - Question about the future of.
David Hucklesby wrote: The validator still needs a DTD though. If you mean the W3C validator, then no, it just got experimental HTML5 support. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HTML/XHTML/XML - Question about the future of.
Kepler Gelotte wrote: There is also another reason to use XHTML instead of HTML and it does not involve browsers. When representing your code (xHTML) as XML, it can also be viewed as data. A perfect example of this is screen scrapers which read your web pages to pull specific content out of them. Any practical instance of which, in practice, has to deal not only with tag soup HTML but also malformed XML, which rather undermines this point. -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Replacing a paragraph with JS [was: Re: [WSG] JavaScript clarification please]
. Generally, when
inspecting the navigator object to try to determine if it is Internet
Explorer, you need to try to exclude alternative possibilities first.
If, however, you merely want to detect the Trident web engine that
underpins Internet Explorer and certain other browsers, there are more
reliable methods available:
* Conditional comments in HTML:
http://reference.sitepoint.com/css/conditionalcomments
* Conditional comments in JScript:
http://msdn.microsoft.com/en-us/library/7kx09ct1(VS.80).aspx
document.write(str.replace(/supNote:/supnbsp;If you want to
view only a specific table, you will have to double-click on each
drop-down Title, in order to view individual tables./, supInternet
Explorer User's Note:/sup You may have to triple click the drop-down
title, in order to view individual tables.));
This is very strange code. If an HTML document is still being parsed
when a document.write called is executed, then the passed string will be
inserted at that point and parsed before the rest of the document. See
also the documentation of Mozilla's implementation:
https://developer.mozilla.org/En/DOM/Document.write
Otherwise it will perform an implied document.open call and wipe the
existing document before parsing the passed string as a new document.
The intended results of your str.replace appears to be the string
supInternet Explorer User's Note:/sup You may have to triple click
the drop-down title, in order to view individual tables. This isn't
variable and the replace() method does not alter the original str
variable, so I don't understand why you aren't using that string directly.
Now, another problem is your regular expression contains a syntax error,
since / is being used as a delimiter but hasn't been escaped inside
/sup (for instance with the regular expression character escape: \/.
This syntax error would have been detected if you'd tried executing the
code with a JS debugger (i.e. turn on debugging in IE; Companion.JS may
also prove useful to you).
Note that the character . also has special meaning in regular
expressions. See also:
http://www.regular-expressions.info/reference.html
http://www.regular-expressions.info/javascript.html
In general, I'd suggest keeping your markup separate from behavior for
reasons of separation of concerns and performance rather than mixing the
two together the way you're doing here. Here's a couple articles to help
with that:
http://www.wait-till-i.com/2007/11/12/the-seven-rules-of-unobtrusive-javascript/
http://www.sitepoint.com/print/javascript-from-scratch
and here's a quick example:
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd;
html lang=en
head
meta http-equiv=Content-Type content=text/html; charset=utf-8
titleProgressive enhancement example/title
/head
body
!-- This raw markup should provide core content and functionality. --
p id=textText without JavaScript./p
!-- Rest of the raw document goes here. --
!-- All script put at end of document to ensure everything has been
parsed into the DOM and to maximize performance:
* http://peter.michaux.ca/article/553
* http://developer.yahoo.com/performance/rules.html#js_bottom
--
script type=text/javascript
!--
// Wrap everything in an anonymous function to prevent pollution of the
// global context:
(function() {
// Keep string definitions, which we might want to localize or modify,
// separate from the presentational logic:
//
// http://en.wikipedia.org/wiki/Separation_of_concerns
//
var strings = {
'newText':'Text with JavaScript.'
};
// Check interfaces exist before trying to use them.
// Yes, the level of checking here is a little bit paranoid.
if (typeof this.window !== 'undefined'
typeof this.window.document !== 'undefined'
typeof this.window.document.getElementById !== 'undefined' ) {
// Get a reference to the P HTMLElement instance:
var p = this.window.document.getElementById('text');
// Internet Explorer does not support the standard textContent
// feature of the HTMLElement interface:
//
// http://developer.mozilla.org/En/DOM/Element.textContent
//
// But it does implement a similar non-standard property, innerText:
//
// http://msdn.microsoft.com/en-us/library/ms533899(VS.85).aspx
//
// We can use typeof to detect which property is defined, if any:
if (typeof p.textContent !== 'undefined') {
p.textContent = strings.newText;
}
else if (typeof p.innerText !== 'undefined') {
p.innerText = strings.newText;
}
}
})();
//--
/script
/body
/html
Hope that helps.
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] JavaScript clarification please
Christian Snodgrass wrote: I second that. They actually have a LOT more bad information than they do good information, and what little good information they have is often quite out of date (so, it was good information, but not anymore). And when they _do_ add new information, they get that wrong too: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-August/016157.html -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Flash replace Javascript in Future?
Webb, KerryA wrote: Johan Douma wrote: Flash is on 99.9% of the computers. Which is the sort of claim made often by Adobe. But, if we're talking about a recent version of Flash on 99.9% of computers, that's a different matter. I think that's somewhat unfair. Adobe go out of their way to provide a breakdown of the headline figure: http://www.adobe.com/products/player_census/flashplayer/ http://www.adobe.com/products/player_census/flashplayer/version_penetration.html (Also it's 99% not 99.9% - by Adobe's own figures 1 in 100 people don't have Flash, which is a not insignificant number if you're talking about, say, boosting sales from a website.) -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] re: Semantic use of rel and rev in anchors
Susan Grossman wrote: Since there are no standard values for rel http://www.w3.org/TR/REC-html40/types.html#h-6.12 are the standard link types for REL and REV. They are open to use with other values, as specified by a scheme specified by a PROFILE link on HEAD (not that PROFILE has seen much adoption). -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
Stuart Foulstone wrote: Actually, the label tag wrapped around form input is the old traditional method. The for attribute method was introduced later to allow designers greater flexibility in positioning/styling forms whilst maintaining accessibility. Really? As far as I can tell looking at the historical record, Internet Explorer 4.0 and HTML 4.0 introduced the LABEL element, including the FOR attribute, IE didn't support implicit association until version 7.0, and the old tutorials tended to teach it the FOR attribute, so I'm not sure what tradition you're referring to. http://www.w3.org/TR/1998/REC-html40-19980424/appendix/changes.html#h-A.1.1.1 http://www.w3.org/TR/1998/REC-html40-19980424/interact/forms.html#h-17.9.1 http://www.sxlist.com/TECHREF/language/html/ib/Forms/label.htm http://www.insidedhtml.com/tips/elements/ts17/page1.asp http://www.cs.tut.fi/~jkorpela/forms/kbd.html -- Benjamin Hawkes-Lewis -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
Johan Douma wrote: I've always used label arount input fields labeltext: input type=text //label without the for= attribute. I've never had problems with it, and I don't think I've ever seen any recommendation against it. There's a discussion about some problems with that pattern at: http://www.w3.org/TR/WCAG20-TECHS/H44.html and http://green-beast.com/blog/?p=254 I'd suggest just using: div class=fieldlabel for=field-idLabel text:/label input id=field-id name=field-key type=text/div (substituting whatever you feel most appropriate for DIV) -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Flash replace Javascript in Future?
Charles Ling wrote: I would like to get some opinion from you all, that would Flash 10 or ++ will replace JavaScript in the future? According to this blog : http://ajaxian.com/archives/flash-10-and-the-bad-news-for-javascript-interaction. I'm not entirely sure Christian's right that Flash 10 Security breaks all JS-triggering of Flash functionality rather than just preventing it triggering the File dialog. (Given how important this is for accessibility, I rather hope not!) I found that alot of media website started to replace Javascript to play their audio/video and of course Flash required to be install as third party plugin and had to be updated (which is annoying). Alternative possibility: over the next decade (the lifetime of a typical IE version), this use-case for Flash will disappear, except as fallback for native HTML video and audio elements: http://www.whatwg.org/specs/web-apps/current-work/#video http://www.whatwg.org/specs/web-apps/current-work/#audio -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
