Re: [WSG] Examples of great high-school websites?
Visitors with images switched off wont see what the main nav links are and those with javascript off wont be able to use them! Furthermore, those with the computers switched off won't see anything at all . . . Bob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Examples of great high-school websites?
ROFLOL! -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of designer Sent: Sunday, January 18, 2009 4:38 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Examples of great high-school websites? Visitors with images switched off wont see what the main nav links are and those with javascript off wont be able to use them! Furthermore, those with the computers switched off won't see anything at all . . . Bob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] Microformats Accessibility
on microformats.org, it suggests the ABBR element and title attribute for machine code. however, title attribute for this element will be read out to a screen reader user. we are considering having an output of span class=namehuman valuespan class=value title=machine value/span/span however its an empty span. this method of empty spans is also suggested on microformats.org to combat accessibility issues, but wanted your suggestions / thoughts? Obviously it is a clash of HTML standards VS accessibility. I've chosen the span option because I think accessibility is more important. Ben *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
Ben Rowe wrote: Obviously it is a clash of HTML standards VS accessibility. Actually, it's a clash of microformats' misappropriation of HTML standards VS accessibility... An empty span won't kill anybody though. What you lose in code purity you gain in a slightly more accessible solution (as long as tools that consume those microformats actually recognise the span solution...been a while since I checked if that's the case - otherwise, it's purely academic). P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Examples of great high-school websites?
Educational Networks has been courted our administration (for El Camino Real High School in southern California) for the last couple of years. I finally let them come to show me their stuff, intending to show them what I had put together for my school site as a discussion starter; they are not used to talking to people who have done this sort of work--content management is the magic wand they offer to the schools, so when there's something that's already set up that way they have a tough time getting past a solution that isn't theirs: http://ecr.lausd.k12.ca.us (Please note that the Student Info page, linked from the navbar, is entirely designed by and controlled by a former student--it is rife with errors and designed without any regard to consistency with the overall site design. I know about it and have no time to do anything about it except ask for forgiveness at present.) I welcome comments, of course, but that's not the reason I'm sending this message. Most of the site is content-managed (I did the PHP myself, no use of any sort of CMS framework or engine--for better or worse) and I have used Mike Cherim's contact form (although I styled it to fold in with the site, I think). The rep they sent wasn't really very conversant on the technology, but did write down all of my issues, including these points: 1. All their sites (and they have done MANY) look exactly the same if you squint: fixed-width, scrolling banners, etc. 2. All their sites load slowly. 3. All their sites are invalid for HTML and CSS 4. All of their sites fare unfavorably against any accessibility guidelines 5. All of their sites weren't as good (IMHO) as what I had already made etc. When the rep went back to EN with her tail betwixt her legs, she must have talked to some tech people, then sent back a note with her signature; this is an excerpt from her note. Perhaps this will help clarify their position, at least as of last year. And one would think that, regarding the last comment about accessibility, if they can do it as a tech support request, why not just build it into ALL their sites? It's all part of the deep structure of the CMS, right? Well, it should be. . . *** EXCERPT FROM EN'S RESPONSE*** 4) CSS vs. Tables. This is a vary valid discussion and here are the considerations in making a decision as to what approach to take: - All our sites use CSS for a lot of centralization in terms of backgrounds, fonts, styles, it is efficient, works robustly and beautifully. - Most of the tables are not handled through CSS because CSS is not reliable across various browsers the way each renders HTML. We design our sites to be correctly visible from IE 5, Firefox, even on Mac's with IE 5 (which is no longer supported by Microsoft). Our public sites should operate properly even on exotic OS's or old browsers as in many communities people have old computers with old browsers. When tables are implemented one can also correctly handle more complex tables. CSS is fine with simple listing tables such as a 1 X N matrixes (like one can see on the homepage of ECR), but imagine a 3X3 matrix where the requirement would be to merge the first two cells starting from the most left column for only on the top row. This would be a nightmare to handle through CSS, thus the correct choice would be to use the Table approach. - The sites we built are portals with unified navigational structures. The header, footer, left nav bar (if there is one) would come from includes using a proprietary technology (a bit like portlets) which also works most efficiently with tables, rather than CSS. http://en.wikipedia.org/wiki/Liquid_web_design#Liquid_versus_fixed_layoutshttp://en.wikipedia.org/wiki/Liquid_web_design#Liquid_versus_fixed_layouts has an excellent discussion about Table vs. CSS. At Educational Networks we do follow closely all new technologies and implement them as they become widely available and have proven track records of being robust and mainstream. A good example would be RSS enabling most dynamic sections and ICAL compatibility of our calendars. There are numerous Web 2.0 technologies with lots of eye candy and we constantly evaluate them before reliably implementing them. For example, last year we AJAX enabled several applications of the CMS in the back-end such as Food Menu and Events Calendar, and Settings as it was the appropriate thing to do for ease of use. But with each novelty there is the risk of making the systems sluggish or not compatible with older computers/browsers and sometimes this is too high of a price to pay for eye candy and thus in many instances we choose to err on the conservative side. 5) Liquid vs. Fixed Pixel: Same issue, of course sites can be designed with liquid considerations in mind, yet, graphic design is also very important for schools and is one of the most important parameters in generating traffic. People like attractive designs. Fixed
Re: [WSG] Microformats Accessibility
Hey Ben, Just a note... for now the following should be used instead: span class="name"human valuespan class="value"machine value/span/span The span class="value" title="machine value"/span is still in brainstorming so should not be used yet. Reference: http://microformats.org/wiki/value-excerption-pattern-brainstorming#parsing_title_from_empty_value_elements Cheers, Anthony. Patrick H. Lauke wrote: Ben Rowe wrote: Obviously it is a clash of HTML standards VS accessibility. Actually, it's a clash of microformats' misappropriation of HTML standards VS accessibility... An empty span won't kill anybody though. What you lose in code purity you gain in a slightly more accessible solution (as long as tools that consume those microformats actually recognise the span solution...been a while since I checked if that's the case - otherwise, it's purely academic). P ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
Re: [WSG] Microformats Accessibility
Anthony Ziebell wrote: Just a note... for now the following should be used instead: /span class=namehuman valuespan class=valuemachine value/span/span/ And rely on CSS to display:none that nested span? -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
Yes, until the brainstorm is approved and made standard. Hopefully soon, to remove the requirement of extra CSS. You could apply a span.value style, or alternatively add 'hidden' as an extra class style and apply it to that. span.value style would probably be sufficient. Regards, Anthony. Patrick H. Lauke wrote: Anthony Ziebell wrote: Just a note... for now the following should be used instead: /span class="name"human valuespan class="value"machine value/span/span/ And rely on CSS to display:none that nested span? ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
Re: [WSG] Microformats Accessibility
Anthony Ziebell wrote: Yes, until the brainstorm is approved and made standard. Hopefully soon, As the lord of microformats Tantek seems so vehemently opposed to it, I sincerely doubt it will happen any time soon. It's now been roughly three years since the debate around ABBR issues first started, and little visible progress seems to have been made. Who knows, maybe the cynic in me will be pleasantly surprised, but I won't hold my breath... P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
Yes, well thankfully there is a workaround. The ABBR element and title with machine code is a serious problem so far as accessibility is concerned. Regards, Anthony. Patrick H. Lauke wrote: Anthony Ziebell wrote: Yes, until the brainstorm is approved and made standard. Hopefully soon, As the lord of microformats Tantek seems so vehemently opposed to it, I sincerely doubt it will happen any time soon. It's now been roughly three years since the debate around ABBR issues first started, and little visible progress seems to have been made. Who knows, maybe the cynic in me will be pleasantly surprised, but I won't hold my breath... P ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
Re: [WSG] Examples of great high-school websites?
And yes, all, I hadn't checked in a week or so, and I have some validation errors on several of my site's pages--will get to them when back at work Tuesday. Kind of embarrassing, but that's how it is today. Alan At 05:29 PM 1/18/2009, you wrote: Educational Networks has been courted our administration (for El Camino Real High School in southern California) for the last couple of years. I finally let them come to show me their stuff, intending to show them what I had put together for my school site as a discussion starter; they are not used to talking to people who have done this sort of work--content management is the magic wand they offer to the schools, so when there's something that's already set up that way they have a tough time getting past a solution that isn't theirs: http://ecr.lausd.k12.ca.us *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] JavaScript and Accessibility
Hey group, Does anyone have any ideas on standards based form validation, which is non-obtrusive, however remains accessible? Reason I ask, is that some form validations inject an element say under a form input, explaining the error. Now, without any alerts, how would a blind person / screen reader pick up the fact that the element is now there and read out this error? Has anyone been able to cater for this requirement? Thanks, Anthony. ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
Re: [WSG] JavaScript and Accessibility
I'll confess my ignorance on this issue, but how do screen readers handle DHTML type injection of content into the DOM? Without using alerts, you could add the warning into the actual document. But how does a screen reader know the document has changed? L. On Mon, Jan 19, 2009 at 4:30 PM, Anthony Ziebell anth...@fatpublisher.com.au wrote: Hey group, Does anyone have any ideas on standards based form validation, which is non-obtrusive, however remains accessible? Reason I ask, is that some form validations inject an element say under a form input, explaining the error. Now, without any alerts, how would a blind person / screen reader pick up the fact that the element is now there and read out this error? Has anyone been able to cater for this requirement? Thanks, Anthony. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
Without using alerts, you could add the warning into the actual document. But how does a screen reader know the document has changed? For starters: http://dev.opera.com/articles/view/introduction-to-wai-aria/ Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
Isn't 'aria-required' a non-standard attribute? Rimantas Liubertas wrote: Without using alerts, you could add the warning into the actual document. But how does a screen reader know the document has changed? For starters: http://dev.opera.com/articles/view/introduction-to-wai-aria/ Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***