Re: [WSG] SilverLight
On 10/30/07, Christian Montoya wrote: On 10/30/07, Derek Featherstone [EMAIL PROTECTED] wrote: Christian - do you have a reference for that anywhere? I'd be really interested in seeing it (as I'm sure others would be too!) Just read the spec on XAML, which is what Silverlight uses: http://msdn2.microsoft.com/en-us/library/ms752059.aspx Hi Christian - I actually meant a reference on this part of your statement: [because Silverlight uses XML] Microsoft claims that Silverlight is much easier for screen readers, search spiders, etc. to work with. Can you show us where they claim it is much easier for screen readers, search spiders to work with? THAT is what I want to see... Thanks, and sorry for my lack of clarity... Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: +1 613-599-9784 1-866-932-4878 (toll-free in North America) Work: http://www.furtherahead.com Blog: http://www.boxofchocolates.ca Learn: http://north.webdirections.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] SilverLight
On 10/29/07, Christian Montoya wrote: ... Silverlight is rendered XML while Flash is a compiled format. Therefore, Microsoft claims that Silverlight is much easier for screen readers, search spiders, etc. to work with. Christian - do you have a reference for that anywhere? I'd be really interested in seeing it (as I'm sure others would be too!) Thanks, in advance... Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: +1 613-599-9784 1-866-932-4878 (toll-free in North America) Work: http://www.furtherahead.com Blog: http://www.boxofchocolates.ca Learn: http://north.webdirections.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] CSS Driven?
On 12/16/05, Thomas Livingston wrote: If I have to use a table now, it it _not_ going to be a horrible retro nested mess. It's to achieve something I can't achieve otherwise. Hi Tom - I don't mean this as a sarcastic question or anything. I fully admit I may have missed this if it was already discussed, but I'm curious to know if you have examples of this - things you couldn't have achieved in other ways? It sounds odd, but if you have examples, I'd be very curious to see them... Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] positive-discrimination === not positive and IMG properties
On 12/15/05, Ben Curtis wrote: The alt text is removed from the element if the image is loaded. It's a very simple htc that runs this code for each image after the page loads: if (element.complete) element.alt = ''; You attach it to the img selector in your css, or a more specific selector if you don't want all images to be affected. I can't see why you'd want it to have an effect on any images, to be honest. I would assume that the blind have their browsers set to not load images. I may be dreadfully wrong in that assumption, but if the images don't load then this code has no effect and the alt text remains. Dreadfully wrong. Well, you said it, not me :-) The blind have just as many varied setups and configurations as the unblind. If you take away alt text, you take away *critical* information. Even if you target specific images via CSS selectors, I'd question whether nor not it should be removed at all. After all - how do you decide which ones to take away and which ones not to take away? OK - let me rephrase that to be more clear: Don't remove the alt text - it is there for a reason and taking it away is the opposite of web standards. Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
On 11/14/05, Geoff Deering wrote: Why can't the braille software detect an empty form element and inform the user it requires data? Is this an authoring tool problem or a problem with the way standards are prescribed? Agreed, Geoff. We really do need to know more. We'll need to add this to the hitlist for the WaSP Accessibility Task Force. It is something that is of concern to all - I'll see about running some tests with a local braille display user and see what I can determine from his tests... Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Accessibility: Default placeholders
On 11/14/05, Geoff Deering wrote: Mandatory data fields, Required data, fields that require correct data after validation should all be grouped together with a *fieldsetlegend*. This informs all users of the requirements of that data. Indeed - one of my favourite techniques: http://simplyaccessible.org/examples/required-form-fields This standard of putting an asterisks * after (or before an input field) does not only not inform an unsighted user, it often gives the indication after they have tabbed through the field, to late for them to manage their input without back tracking. Agreed. Putting them after *visually* and leaving them before in source order, and as part of the label can be really useful - its semantically meaningful, can be emphasized (using label em /em/label) as shown in the second example on that page is useful. You could easily use the same technique to emphasize the text required instead of an asterisk. Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] simplyaccessible.org
On 10/12/05, Nick Lo wrote: I did want to comment that the form error in the label suggestions Derek gave have really got me thinking about how my CMS returns users to forms and alerts them. Hi Nick, That's good - that was my intent! Actually, that was my intent with most of what is already there, and will be there soon (read: there are more examples on the way - and, incidentally I've added a feed to the site so that people can be notified when I post a new example. I can't guarantee I'll be posting a lot more there beyond what I presented at WE05, but I will be posting the rest of those examples over the next while) I presume that what would be best would be a combination of a message like Please check the errors indicated in the form below at the top of the form and have the this must not be blank on the relevant field(s)? I think that would be very reasonable, yes. For what it's worth, I've had a tough time abstracting the examples, both in preparation for presenting them at WE05, and for posting them on the web. Not presenting them in context makes certain parts difficult - cf. my use of the zoom layout to change *only* the form layout itself, and nothing about the colours/contrast/size of the rest of the page. At a certain point, though, I needed to leave the rest to your imagination. Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] simplyaccessible.org
On 10/11/05, Terrence Wood wrote: Derek, can you update your examoples to use fieldsets instead of divs to group the form controls together? I do use fieldsets to group form controls together but in most cases, there is one fieldset around all the items in one form - the divs are there to provide additional style hooks to create CSS based form layouts and to allow me to create rows without using tables. Or am I misinterpreting what you are saying here? Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] simplyaccessible.org
On 10/11/05, Terrence Wood wrote: Agreed, you are absolutely correct. Doh! I didn't acutally check the source code, no wonder my earlier post was confusing. Sorry Derek. No worries... If anyone *is* interested in replicating Dereks layout without the extra div's try this: snip / for what it's worth - I did try using that at certain points, but generally preferred to add in explicit divs to provide another hook for styling. YMMV - I also preferred to place each row in a block level element so that without author styles each form field and its label is still on a row of its own, though that use case may not be as important. Now then, I'd better get back to it so that I can post the second round of examples... :) Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Meta Keywords?
On 10/7/05, John Allsopp wrote: Get them to ask Hitwise to justify the recommendation, based on anything other than handwaving and superstition. I'd be interested in their response :-) I think it is safe to say that we would *all* be interested in their response, if they prepare one at all... Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] implicit / explicit labels which is better?
On 8/2/05, Patrick Lauke wrote: Mozilla, Firefox, Opera, K-Meleon all cope just as well with an implicit label, making it clickable. Not sure about Safari...anybody care to do a super-quick check? From what I remember, Safari doesn't support clickable labels at all. Not so cool. Mental note - look at the User Agent Accessibility Guideilnes to see if this is *required* or optional. Mental note 2 - send something off to Dave Hyatt to find out if this can be/will be fixed. Oh, and if anyone wants to take care of those two mental notes above for me, that would be great as well... :) Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: Re: [WSG] AJAX and accesibility
On 6/29/05, Drake, Ted C. wrote: re: http://www.boxofchocolates.ca/archives/2005/06/12/javascript-and- accessibility After reading this post, I began thinking that the solution may be to seperate javascripts into basic and advanced sets. Just as we import advanced style sheets to avoid confusing early browsers, perhaps we can set an option to turn off advanced scripting. snip / Are there any JavaScript people on this list that could comment? As both a JavaScript and an accessibility person, I'll step in for a moment. We (the WaSP Accessibility Task Force) will be looking at all possibilities in depth to determine what kind of scripting and techniques are to be considered safe to be used with screen readers and other assistive technology (we need best practices for dealing with screen magnifiers as well, and need a better understanding of the implications of AJAX type techniques for that group of people) In principle, I don't see anything wrong with a layered approach to JavaScript, much in the same way we layer style sheets. Once we better understand the finer points of the interaction between JavaScript and screen readers (for example), we could in theory determine which things will be safe, and then allow a preferences page to turn off specific portions of the JavaScript. I like your idea of allowing the user to turn off and on portions of the JavaScript via preferences - I don't usually advocate this approach on its own, but in this case, though, it is likely that if they disable JS completely, other sites will stop working as expected. Yes, I know - too bad for the other sites because it is their own fault in the first place. Erring on the side of caution though, a scripting preferences might be useful and less likely to cause other problems. There are a couple of tricky points that we'd need to sort out - directing people to preferences to make the change, ensuring that it is well explained without being too techie, and to avoid having too many options - in my opinion, it needs to be limited to all scripting, core only, and no scripting options - otherwise it gets too difficult to understand. Hope this helps - there are parts I'm being deliberately vague about as the Task Force is only just getting started and we have a lot of work to do... Please be reassured that we are looking at this very seriously with a very talented group of people, and hopefully we'll be making some good progress soon. Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] tel: 613-599-9784 1-866-932-4878 (toll-free in North America) Web Development: http://www.furtherahead.com Personal:http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] CSS List Separator
On Tuesday, June 14, 2005 9:56 PM, Terrence Wood wrote: I completely agree, and have been involved in translating legislation into a web format. It's a shame that the start attribute has been deprecated in XHTML (last I looked). Well, there is always HTML 4.01 for these cases (legislation, such as John has suggested). In such cases, we can still use perfectly well-formed, valid markup. And, in this case, I would argue more semantically correct markup, and likely a better choice of DOCTYPE. As has already been said, simply choosing the right DOCTYPE for the job may not be enough, though, given that we still don't really know to what degree punctuation matters. Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Development: http://www.furtherahead.com Web Accessibility: http://www.wats.ca Personal: http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Best way to train someone in css and web standards
On Monday, May 23, 2005 7:35 AM, Cole Kuryakin - x7m wrote: By proficiency, I mean that I can give them a Photoshop design comp, and they will be able to create an XHTML code foundation as well as a CSS style and positioning spec without too much whining and head-scratching. My plan is to get them completely compeletely trained in these areas before letting them dive into any real project development. Hi Cole, Just a few quick points re: getting these people up to speed. Books and blogs are the order of the day. You might have a suggested reading list for them, including as Kay suggested, Zeldman's Designing With Web Standards. I would also suggest Dan Cederholm's Web Standards Solutions. While that book may seem to be too advanced at the beginning, it digs deep into code and samples. Like Dan's SimpleQuiz series from his blog, there is a lot more to semantics and code then meets the eye, and that can be enlightening for developers to see. Add into the mix a healthy dose of blogs so that they can keep up with and find the latest and greatest, even if it is only 4 or 5 blogs. Web Design World 2004 was held in Boston in December 2004. Molly Holzchlag and Ethan Marcotte did a presentation that is archived online. In that presentation, Ethan deconstructs the conversion of one of Harvard University's web sites from tables to CSS layout. While it doesn't demonstrate every aspect of the code, nor converting a PhotoShop comp into a CSS based layout, I find that it does a great job of demonstrating the ethos and principles behind modern web development. The presentation is linked from here: http://www.ftponline.com/reports/wdwboston/2004/holzschlag/ When you click on the link for the presentation, instead of http: it lists mms: I'm not exactly sure what that protocol is, but clicking the link brings up a message about launching an external app. I just changed it to http: instead of mms: and it worked fine. Finally, re: my plan is to get them completely trained in these areas before letting them dive into any real project development In my opinion, this isn't really a good idea. Here are some things to consider (this is mostly my opinion, based on my experience both as a developer and instructor): 1. if they only know basic HTML, getting them up to speed will take a while. If they are doing nothing but training, they'll quite possibly get bored, and web standards will be to blame. 2. learning these new techniques are best done with real projects. Contrived examples are usually ok, but work on a real project is much more effective for learning as they are doing something real and will have different motivation for getting the job done. 3. From a learning perspective, you have to start small. Get them working on a small component of a real site. Something like a nav bar, or a footer using only semntically sound HTML and CSS would be useful. Get them to do it on its own, and then you show them how that fits into the big picture of the rest of the site (which you will presumably be doing). 4. For those small pieces, point them in the right direction - get them started by showing them some examples, and see if they can make something work using the examples as a model. You can then work with them to deconstruct their attempts and really help them understand what is going on. 5. You have to keep challenging them - they need to move from creating a nav bar with HTML and CSS to being responsible for the entire header, to header plus footer plus secondary nav perhaps, and then responsible for all an entire site. OK, I could write forever about this, but that is more than enough to digest for now... Hope this is helpful to you... Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Development: http://www.furtherahead.com Web Accessibility: http://www.wats.ca Personal: http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: Focus highlighting, was Re: [WSG] Some links for light reading (30/11/04)
On Tuesday, November 30, 2004 9:09 AM, Kornel Lesinski wrote: Does that really matter? Yes, focus highlighting does matter. I come across this daily -- and I'm a keyboard user by choice... In Firefox and IE there is a focus border anyway. Which isn't exactly prominent - it provides a faint outline around the element. Changing the background and text colours in the CSS is much more prominent and is easier to spot. Besides, we add :hover effects to things for mouse users - why wouldn't we also provide similar benefit to keyboard users? IE doesn't support :focus or outlines, so there isn't much you can help. Right, however, IE (mistakenly, I suspect) treats :active the same as :focus. Adding a separate rule for IE and :active will provide the benefits for IE keyboard users... For example: ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: Focus highlighting, was Re: [WSG] Some links for light reading (30/11/04)
Sorry about that -- it appears that pressing enter while holding down the
control key sends the message ( a new keystroke I didn't know about...)
Here's the complete message I was trying to send:
On Tuesday, November 30, 2004 9:09 AM, Kornel Lesinski wrote:
Does that really matter?
Yes, focus highlighting does matter. I come across this daily -- and I'm a
keyboard user by choice, not someone who has no choice but to use the
keyboard...
In Firefox and IE there is a focus border anyway.
Which isn't exactly prominent - it provides a faint outline around the
element. Changing the background and text colours in the CSS is much more
prominent and is easier to spot. Besides, we add :hover effects to things
for mouse users - why wouldn't we also provide similar benefit to keyboard
users?
IE doesn't support :focus or outlines, so there isn't much you can
help.
Right, however, IE (mistakenly, I suspect) treats :active the same as
:focus. Adding a separate rule for IE and :active will provide the benefits
for IE keyboard users...
For example:
a:focus {color: #346095; background-color:#fff;}
a:hover {color: #346095; background-color:#fff;}
a:active {color: #346095; background-color:#fff;}
So, please, please, if you want to make your sites more accessible to
keyboard users, add :focus and :active rules to match your :hover rule.
Best regards,
Derek.
--
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784; toll-free: 1.866.932.4878 (North America)
Web Accessibility: http://www.wats.ca
Personal: http://www.boxofchocolates.ca
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
RE: Focus highlighting, was Re: [WSG] Some links for light reading (30/11/04)
On Tuesday, November 30, 2004 10:19 AM, Patrick Lauke wrote:
And you can group the above and save yourself repetition. In one
of my stylesheets, for instance, I have
#navbar li a:focus,
#navbar li a:hover,
#navbar a:active {
background: #fbfbfb;
}
I seem to recall Tommy talking about a problem when all three are specified
in the same rule, but I can't recall right now. Though perhaps it was only
mentioned and never resolved. Might be able to find it in the forum archives
somewhere... http://www.accessifyforum.com
I'll let you/everyone know if I find anything
Best regards,
Derek.
--
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784; toll-free: 1.866.932.4878 (North America)
Web Accessibility: http://www.wats.ca
Personal: http://www.boxofchocolates.ca
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
RE: [WSG] IE's New JavaScript Blocking Feature
On Friday, November 26, 2004 2:53 PM, Mark Harwood wrote: The best and only way i do pop-ups is href=http://google.com/; onclick=window.open(this.href, 'popupwindow', 'width=400,height=300,scrollbars,resizable');return false; this allows you to do whatever you like with the link and also makes it valid, right click-able and so forth.. Remeber to put onKeypress too Please, don't add onkeypress to this in the name of device independence... Onclick works just fine for keyboard users and for users that use alternative devices that emulate keyboard usage. If you add onkeypress you will quite possibly do more harm than good -- someone that uses a keyboard for navigation etc won't be able to go anywhere because the pop up will keep appearing. If I'm on that particular link myself, even pressing the tab key to move to the next link will cause the dialog to appear. Trying to open a new tab with Ctrl + T, or open my feedreader (Sage) with Ctrl + S will cause the popup to appear. It can actually become quite frustrating when onkeypress is used like this... Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Accessibility: http://www.wats.ca Personal: http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] IE's New JavaScript Blocking Feature
On Friday, November 26, 2004 3:57 PM, Mark Harwood wrote: OnActivation would proberly be better to use, only reason i state to use onKeyPress is that validators moan if u dont use it. That's the problem -- there is no onactivate, but that is what they probably should have called onclick though. As for using onkeypress, if the validators (by which I assume you mean Bobby, et al) then, they need to get a clue. The automated tool is only there to help, not to be the final arbiter of what is and isn't accessible. My vote: let the automated checkers moan about this all day. Ignore them. Don't add onkeypress in the name of accessibility and device independence... Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Development: http://www.furtherahead.com Web Accessibility: http://www.wats.ca Personal: http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Fieldsets can be used outside the box - Correct use of fieldset
On Tuesday, November 23, 2004 11:22 AM, Ted Drake wrote: I think a fieldset could be used outside a form if you are using it to group similar links. We can fixate on the name or look at the purpose. It says, the fields inside it are related. If the standards say it can be outside a form than we can use it to group similar objects. Let's just clarify this -- the DTD says that a fieldset can be outside a form, but only really because it is defined as a block level element. I don't think that supercedes the intent of the element though. As you said, look at its purpose: The FIELDSET element allows authors to group thematically related controls and labels. http://www.w3.org/TR/html4/interact/forms.html#edef-FIELDSET And controls are form fields of some sort: buttons, checkboxes, radio buttons, text boxes, textareas, file selects, etc... http://www.w3.org/TR/html4/interact/forms.html#h-17.2 I'd say that using fieldset and legend to present groups of links in this way is twisting its meaning completely. If you want the closest semantic relationship possible for presenting a list of related links, you might consider a definition list. The title of the group of links is the dt/dt and each of the links could be the dd/dd. You might even use a properly-coded, semantically-structured table to do the job. My preference would be to use appropriate headings with a ul/ul, or even a nested list structure, but I can't see using fieldset for it... Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Accessibility: http://www.wats.ca Personal: http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Creating Nice Pop-Ups
On Wednesday, November 10, 2004 6:47 AM, Patrick Lauke wrote: Incidentally, I've discussed this before, but...onclick is implemented in practically all current browsers as a non-device-specific event, as it is triggered by keyboard access as well (on elements that can receive focus via keyboard tabbing, anyway, i.e. links and form elements). Patrick is, as usual, bang on with this. Further - unless it is done very carefully, onkeypress redundancy makes keyboard navigation next to impossible in various browsers. In many cases it causes unintended consequences - like not allowing one to tab to the next link, causing popups to occur, or changing stylesheets without the user really wanting to change stylesheets. Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Accessibility: http://www.wats.ca Personal: http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Flyout menu questions
Pringle, Ron wrote: Ideas, criticisms, suggestions and opinions welcomed. http://www.aurora-il.org/testsite/index.htm Hi Ron, I know this isn't exactly what you were looking for, but I went to do a quick navigation test via keyboard and found that I couldn't. You should remove the onkeypress redundancy for your style sheet switcher. As it stands, I can't tab past the stylesheet switcher because of the onkeypress handler. In many browsers onkeypress can break keyboard navigation - certainly an unintended consequence - where trying to help accessibility actually hinders it. Onclick is a misnomer, at least the way it has been implemented in browsers. It actually behaves more like onactivate, so onclick will be just fine for keyboard users as well. Hope this helps... Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Accessibility: http://www.wats.ca Personal: http://www.boxofchocolates.ca ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Question on tabindex
Now, what is the best order of the tabindex? Starting with the main nav and ending with the footer links seems obvious, but should the order in between be: content, right column or right column and content? Hi Luc -- I'd suggest you might want to just forego the tabindex completely. You've already got quite a reasonable logical flow within that test page anyway -- one that pretty much anyone could use, based on the order of your source code. Tabindex can actually cause some problems, so we generally just recommend leaving it out. See http://www.wats.ca/articles/keyboardusageandtabindex/62 for a few more details and some test results... Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Accessibility: http://www.wats.ca Web Development: http://www.furtherahead.com Personal: http://www.boxofchocolates.ca * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
RE: [WSG] Internal CSS in XHTML served as application/xhtml+xml
Patrick wrote:
have a read through
http://devedge.netscape.com/viewsource/2003/xhtml-style-script/
...but to answer the question quickly: it should work if you use
//![CDATA[
//]]
Right, but that only deals with JS embedded in its own script/script
block. I've used that before if I wasn't able to remove the JS and put it in
an external file.
This breaks down though, for references like this in the page for
bookmarklets (pardon the length):
a href=javascript:var l=document.links.length;var s='';for
(i=0;il;i++){var lk=document.links[i];s+='tr valign=top';s+='td' +
lk.innerHTML + ' /td';s+='td' + lk.title + ' /td';s+='tda
href='+lk.href+'' + lk.href + '/a/td';s+='/tr';}s='Links for:
'+document.location.href+'table border=1 style='font:x-small verdana'tr
valign=topthText/ththTitle/ththURL/th/tr'+s+'/table';var
lw=window.open('', 'lw',
'');lw.document.open();lw.document.write(s);lw.document.close();
Links and Titles
/a
Adding proper escape sequences to inline JS in this case just won't work, or
perhaps I'm missing something?
Best regards,
Derek.
--
Derek Featherstone [EMAIL PROTECTED]
phone: 613.599.9784; toll-free: 1.866.932.4878 (North America)
Web Accessibility: http://www.wats.ca
Web Development: http://www.furtherahead.com
Personal: http://www.boxofchocolates.ca
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
*
RE: [WSG] Internal CSS in XHTML served as application/xhtml+xml
This breaks down though, for references like this in the page for bookmarklets (pardon the length): but wouldn't you say that bookmarklets are a bit of a perversion of the standard, in which case it becomes academic to discuss how these can be served in a standards-compliant way? Oh, I agree completely -- I was just hoping that someone somewhere might have come across a method that would let me serve it up properly... What I'll likely end up doing is serve that page as text/html - it's the only solution that I can see, if I want to serve the rest of the site as application/xhtml+xml I won't lose too much sleep over it... ;) Cheers, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Accessibility: http://www.wats.ca Web Development: http://www.furtherahead.com Personal: http://www.boxofchocolates.ca * The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help *
