Re: [WSG] Accessibility standards - for commercial consumption
Mary Krieger wrote: In response to comments from Gunlaug and Patrick on the ease of use of the documents for WCAG 2, I was moved to have a try at revising a short passage - not to change the technical content just to reduce the fog. ... If this kind of rewriting is useful, I would be happy to help. My point was that *we*, the community, should not be doing this. It's the WAI itself who should be providing us with a document that's understandable and usable. As helpful as translations/revisions here may be, they should be fed back to the W3C directly. 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 __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** 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 standards - for commercial consumption
Do you want to talk about the HREOC guidelines on pdfs and how they are ignored by almost all of Australia (including most Government departments). Wait. There are HREOC guidelines for pdfs? http://www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html#s2_3 http://www.hreoc.gov.au/disability_rights/webaccess/anao_guide.htm Thank you, I didn't know that before :) Kat NB. Talk about irony - South Australia's strategic plan contains elements of Social Inclusion, but the page itself does not conform to WCAG 1.0 as per the documentation mirrored at Vision Australia. http://www.stateplan.sa.gov.au/ I think pdfs are a small problem in relation to all the other accessibility problems of Australian govt. sites. Kat ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Compromising markup for performance
So we know that some really big sites have some awful markup right? View source on amazon, gmail or google calendar and you'll find things like iframes and inline css js. stuff like td style=white-space: nowrap; class=cornerBookmarksdiv style=overflow: hidden; white-space: nowrap; float: left class=cornerBookmarks etc etc The thing is, their stuff renders really quickly. even on a slow modem connection, gmail is really quite snappy and usable. ie: in some instances, I am sure this is not lazy programming. I know from 1st hand experience reading [1] that there are actual, real, performance benefits with inlining styles and js. Obviously it makes us sick to see markup like that but at the end of the day (and if you're a 'moderate' standards enthusiast like me as opposed to an 'extremist' one) if there's a commercial or user benefit in breaking some rules - its not surprising how these decisions get made. I get the feeling not everyone knows this though and just pans (criticises) big companies sites without knowing how they came up with that result. It may be useful to hear of some experiences where your own markup has been compromised for performance. For someone learning this stuff from scratch i think this can be useful to know why some sites are doing this - and what they should follow or avoid for their own projects. as an aside, i think it'll be really interesting to see how Doug working for Google [2] will effect their markup. cheers, pete [1] - http://www.amazon.com/gp/product/0735713243/ [2] - http://stopdesign.com/log/2006/05/27/going-to-google.html ~~ Pete Ottery Head of Design News Interactive A News Limited Company Address: Level 3, 2 Holt Street, Surry Hills NSW 2010 Australia Visit the News Interactive Network of sites: NEWS.com.au | australianIT.com.au | escape.com.au FOXSPORTS.com.au | realestate.com.au | careerone.com.au carsguide.com.au | homesite.com.au ~~ ** 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] Compromising markup for performance
as an aside, i think it'll be really interesting to see how Doug
working for Google [2] will effect their markup.
I don't know that it will that much. I was in Mr Bowman's full-day workshop
during webStock*. You can tell he's quite obsessive about things being real
neat tidy - it comes through in his code and presentation very clearly - but
one thing he did mention is that Google tests applications in terms of
microsecond responses - both in terms of server processing and rendering on the
client.
He outlined that rules like
#main p em.special {
/* style here */
}
May be great in our stylesheets, but the browser ends up having to make
decisions like this:
1. Am I inside the element whose id is 'main'?
2. If so, am I inside a 'p' element?
3. If so, am I processing an 'em' element?
4. If so, does it have the class 'special'?
5. Ok, I'll apply the style rule here
Doug stated that in these type of cases, where microsecond improvements are a
big deal for *perceived* speed improvements (like the ones you've noticed with
Amazon et al) it's better to just write rules like:
em.special {
/* blah */
}
(two decisions)
Or simply
.special{
/*blah blah */
}
(one decision)
I guess that's why you're seeing inline styles - the browser then doesn't even
have to make a processing decision as such, it just applies the style rules
directly to the element in question.
Bear in mind that Doug was involved in the development of the UI for Google
Calendar, so the code you see there may be an indication of coding conventions
made for speed adavantages rather than just 'sloppy coding'.
Be interesting to see what comes of Doug's involvement
* http://www.webstock.org.nz
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
[WSG] Out of Office AutoReply: digest for wsg@webstandardsgroup.org
I am on annual leave until Monday 29th May. Please send all urgent web matters to Roger Crew. # CAUTION - This message may contain privileged and confidential information intended only for the use of the address named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you received this message in error please notify the sender or Frankston City Council immediately. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Frankston City Council. Any email message sent or received by Frankston City Council may need to be disclosed by the Council under the provisions of the Freedom of Information Act 1982. Any email message sent or received by Frankston City Council may be saved in Councils Electronic Document Management System. # ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
