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] Federal Court hearing re Virgin Blue website accessiblity
Chris, thanks for bringing it to my attention, I did not know about the up coming court case. I have seen a letter Mr Kerr sent a company regarding an inaccessible website: http://forums.port80.asn.au/showthread.php?t=12018#6 and received and replied to email Mr Kerr sent as a response to my forum comment. Apparently I have a different opinion from Mr Kerr on what makes a web site accessible under the Disabilities Discrimination Act. It should be an interesting case and I am looking forward to the results. This will be very different from Maguire vs SOCOG as it is in the Federal Magristrates Court not the Human Rights Commission. I hope that Mr Kerr's legal team have more than Mr Kerr and a letter from HREOC on their side. Because if I was Virgin Blue, I would have a couple of experts from Vision Australia and a couple of screen reader users to tell/show how they can book tickets via Virgin Blue's website (ala the Target defense last year in the US). -- Nick Cowie http://nickcowie.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Federal Court hearing re Virgin Blue website accessiblity
On Tue, Jan 20, 2009 at 8:03 AM, Nick Cowie cowie.n...@gmail.com wrote: Apparently I have a different opinion from Mr Kerr on what makes a web site accessible under the Disabilities Discrimination Act. Care to expand on that point? Do his views jibe with what most web developers would consider 'accessible'? - Matthew *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
I thought a bit more about this and I realised perhaps a better option would be to display the JS-injected messages and errors that a screen reader could not read but upon submission of the form, reload the page and provide all the messages and errors again (the form could not be completed anyway due to the errors; where else would to send the user to?). This way users browsing with an accessibility aid like a screen reader would not see the injected errors which are a nifty feature but still be presented with them upon submission of the form and the page reload. Why I didn’t think of this earlier is beyond me. D’oh. —Pascal On 20/01/2009, at 12:57 PM, james.duc...@gmail.com wrote: after all it's impossible to tell those users using an accessibility aid like a screen reader from those who do not, and hey, the growing number of users who purposefully disable JavaScript won't see the glitzy JavaScript injected errors anyway. Agreed, and any decent validation is going to be done server-side validation anyway, so you're going to have to (or at least you should) implement the server-side responses in any case. - James -- James Ducker Web Developer http://www.studioj.net.au *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** --- Simon Pascal Klein Concept designer (w) http://klepas.org (e) kle...@klepas.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
A timely blog post by Andy...and this marks the third anniversary of the same issues being rehashed http://forabeautifulweb.com/blog/about/designing_around_haccessibility/ though Ben Ward's efforts are to be noted...see http://forabeautifulweb.com/blog/about/designing_around_haccessibility/#r356 I guess I should make sure my parser handles those... ...btw looking at the examples draws attention to a big usability problem with so-called human dates... (which has little to do with microformats or markup .. its more a problem with culture and education) 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? ... Do you really want to hide a machine date when that may the only thing on the page you can use to tell what the date actually is? It would certainly be nice if people were to learn to write human dates more clearly! Lets ban those yearless dates, dd/mm/ and mm/dd/ sillyness and anything with two digit years! *** 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] Microformats Accessibility
On Tue, Jan 20, 2009 at 8:31 AM, Michael MD md...@spraci.com wrote: ...btw looking at the examples draws attention to a big usability problem with so-called human dates... (which has little to do with microformats or markup .. its more a problem with culture and education) 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? ... Ah yes, the we know screenreader users are having problems with full ISO...but *actually* they're better because they're more unambiguous argument. Strangely, humans have been using human-friendly date/time formats since...forever, and have coped fine with ambiguity for the most part. Human communications are by their very nature fuzzy and ambiguous, and usually this fuzziness is then clarified through additional knowledge (is this blog from the US or from the UK?, when you say 'dinner at 8' i assume you mean 8PM/20:00?, etc). Yes, in a completely ideal world, if microformats weren't creating actual problems to certain users as in this case, I too would jump on the we're disambiguating the web, one datetime at a time bandwagon. But for the time being, while there are known problems, I'd rather wait until the uf community makes a concerted effort to take all the proposed alternatives that can solve the issue into consideration and adopt the best-of-breed one. Do you really want to hide a machine date when that may the only thing on the page you can use to tell what the date actually is? Ok, in both cases, the onus is on the authors of those pages and how ambiguous they are in the content creation. You bemoan the fact that authors haven't made it clear what date/time they actually mean, but then expect the same authors to also put unambiguous full ISO datetime microformats around their fuzzy information? The real solution here is to get these content authors to actually write their information in a clearer way (in clear text), I would suggest. It would certainly be nice if people were to learn to write human dates more clearly! Lets ban those yearless dates, dd/mm/ and mm/dd/ sillyness and anything with two digit years! Absolutely! Sorry, just seen that we're actually saying the same thing here, so nice one. 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/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] JavaScript and Accessibility
From: Chris Knowles
I wouldn't be waiting for ARIA to get out of draft before using it :) It
has pretty good support in browsers already so get stuck in. And because
essentially all you are doing with ARIA is adding attributes to tags,
the worst that can happen is your pages no longer validate - but who
cares if you are making them more accessible?
I think validation is still important to ensure a consistent and future-proof
experience across browsers, but ARIA is definitely needed. So seeing as ARIA
attributes are there to offer a solution to problems introduced by JavaScript,
why don't we use JavaScript to add the ARIA attributes. Using a similar idea to
my Performer script [1] we could add these using CSS:
p id=updates class=aria-live-politeThis content will be updated by an
AJAX-type script/p
A simple script could parse all elements in the DOM tree, and anything with the
class aria-live-polite add the attribute aria-live with a value of
polite. If this was done before any other JavaScript was run it would prepare
the page with ARIA attributes before it is needed, whilst keeping the code
validating. The resulting code in this example would be:
p id=updates class=aria-live-polite aria-live=politeThis content will
be updated by an AJAX-type script/p
Of course, elements with ARIA classes could be styled differently if required:
.aria-live-polite { border: 1px dotted #CCC; }
If JavaScript is not present or disabled, the ARIA attributes will not get
applied. But that won't be a problem, as no other JavaScript will be run anyway.
There are actually a lot of ARIA attribute variations so this idea may not
scale very well, but for simple use it may be a suitable answer to the ARIA /
validation problem.
Chris
[1] http://performerjs.org - add JavaScript features using just CSS classes and
standard attributes. New website and lots more features coming very soon. Get
in touch if you'd be interested in helping / testing.
This message has been scanned for malware by SurfControl plc.
www.surfcontrol.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
From: Chris Knowles yes, so you still run your code through the validator and make sure it only fails on the ARIA attributes - that way you save yourself a whole lot of trouble. I don't really understand inserting attributes with javascript just so you get a tick from the validator? Maybe I'm missing something but what benefit does that bring? And validators will catch up at some point anyway. Quite apart from the satisfaction I get from those green ticks (I loves me them green ticks), I think providing a validating page to the browser is an important part of creating a web that is accessible to all. We all know the problems that certain (ahem) browser manufacturers have with a properly-validating document, but if we have these document definitions in place we should use them. Adding ARIA attributes using JavaScript is therefore part of progressive enhancement, much like using any AJAX-type features is - or at least should be. It's not ideal, I'm not pretending for one minute it is, but that's the web world we live in. Hopefully, in the fullness of time, all these measures will become unnecessary and we'll all bask in the warm glow of browsers that natively handle all the goodies which are being waved in front of our noses (not just ARIA, CSS3, HTML5 etc). But I'm not holding my breath for that day. Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.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
Chris Taylor wrote: From: Chris Knowles I wouldn't be waiting for ARIA to get out of draft before using it :) It has pretty good support in browsers already so get stuck in. And because essentially all you are doing with ARIA is adding attributes to tags, the worst that can happen is your pages no longer validate - but who cares if you are making them more accessible? I think validation is still important to ensure a consistent and future-proof experience across browsers yes, so you still run your code through the validator and make sure it only fails on the ARIA attributes - that way you save yourself a whole lot of trouble. I don't really understand inserting attributes with javascript just so you get a tick from the validator? Maybe I'm missing something but what benefit does that bring? And validators will catch up at some point anyway. -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
Chris Taylor wrote: Adding ARIA attributes using JavaScript is therefore part of progressive enhancement does that actually work? My understanding is that one problem ARIA addresses is that when javascript alters the DOM, assistive technologies don't necessarily get notified of the changes. So do they get notified that you've injected ARIA attributes? -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] JavaScript and Accessibility
-Original Message- From: Chris Knowles does that actually work? My understanding is that one problem ARIA addresses is that when javascript alters the DOM, assistive technologies don't necessarily get notified of the changes. So do they get notified that you've injected ARIA attributes? The thought had crossed my mind, but unfortunately I have no reliable way to test it. If anyone wants to let us know whether this idea is a goer, I'd be very grateful. Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Federal Court hearing re Virgin Blue website accessiblity
2009/1/20 Matthew Pennell matthewpenn...@gmail.com On Tue, Jan 20, 2009 at 8:03 AM, Nick Cowie cowie.n...@gmail.com wrote: Apparently I have a different opinion from Mr Kerr on what makes a web site accessible under the Disabilities Discrimination Act. Care to expand on that point? Do his views jibe with what most web developers would consider 'accessible'? From Mr Kerr's original letter, his opinion appears to that the WCAG 1.0 guidelines priority level 1, 2 and 3 are the be all and end all of accessibility, particularly with regard to the DDA. I take a far more pragmatic approach, particularly when it comes to the 10 year WCAG 1.0 and a number of the priority 3 guidelines that are more likely to make a site inaccessible than accessible. http://wcagsamurai.org/ Personally I find both WCAG 1.0 and WCAG 2.0 to be lacking when it comes to language related disabilities. Both for people with cognitive impairments and those with english as second language, for example people with hearing impairment whose primary language is sign language. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] HTML 5 and XHTML 2 combined
I would feel everyone in cooperation would be the way to go. Browser vendors (going to call them vendors, for short) need to understand that just because they want what they want does not matter as much as what is needed. If a major change is needed and vendors do not want to follow along, then so be it. If every vendor's ideas differed in some respect, then every browser would become an Internet Explorer -type browser. One that does not follow suit with the way things ought to be, in IE's case, is. It should be said to them that whole fact, to save everyone the headache of trying to design for every different browser and what that browser supports/does not support. Sorry, but it is a bit of a touchy subject, especially considering the amount of work that one has to put in with others to get *EVERY* browser to play with one good block of code. How do you imagine this could be reconciled? If you hijack HTML5 to effectively become XHTML2, browser vendors will just again come up with something different conforming to *their* goals. (HTML4.5 or whatever.) Their goals are not as important as what the whole idea of the Web is, and Tim Berners-Lee's/CERN's goals for the Web. Which is, as one major part (responsibility of advocates/vendors/anyone with any part of the Web), universal accessibility. When vendors design for their own goal(s), they are not living up to that responsibility; therefore, their points and concerns mean *NOTHING*, and can be dismissed without a split-second thought, when it comes to the working groups and what is deemed necessary to reach that goal of universal accessibility. And to Benjamin Hawkes-Lewis, to answer your earlier questions When you speak of browser vendors mixing old languages with the new, I'm not sure what you mean, or why it is a problem. The below also explains the above quote of your question. The problem is, that we need to drop what really is heavy and unnecessary luggage, (this luggage being what is not supported in XHTML 1.0 Transitional, at least by my view points). Rift-raft, as Philip said is, the baggage of earlier, arguably poorly thought out, standards. You mentioned creating Transitional and Strict document types, but it's unclear what user problems this would solve or how exactly it would help merge HTML5 and XHTML2. I meant this in the sense of the current X/HTML transitional and strict approaches, as in the reason they were developed rather than just a Strict or Transitional approach (not implementing both, in HTML and XHTML). It could help merge them and solve problems by identifying any conflicting parts of the Standards, any conflicts that you can see that might take place. Focus on the Code that goes into a web page first, you have a small portion of differences that can be resolved by dropping the luggage of earlier, poorly thought out standards. Why would combining HTML5 and XHTML2 would prevent browser developers inventing their own language features? This is best answered by reading the 3 previous posts from this one. What headache are you talking about? The headache stems from the different code necessary to force IE to play nicely and the different codes each browser has made especially for itself (understand the question above about inventing their own language features, where we completely ignore them). But, anyway, like I said, I read your links and can now agree with you. I was just trying to answer your previous questions, not stir up another argument. -- Brett P. On Tue, Jan 20, 2009 at 11:45 AM, Molte molt...@gmail.com wrote: Indeed they should. The problem just might be, that if the browser vendors do not like the language they can simply just avoid supporting it (just like going on a strike). And then what idea is there of a standard that is not supported or used? It's just a question about who has the power to decide the future of the Web. The browser vendors? the coders/developers? us? or just everyone in cooperation? 2009/1/20 Brett Patterson inspiron.patters...@gmail.com Okay, long time posted in this subject. I see where Benjamin is heading with his discussions, and I agree with him. Took me awhile to read and understand his links. But, Olaf, why are browser vendors allowed to choose what is right and wrong with HTML and XHTML, and coders are to play along, and the working groups that build upon HTML and XHTML (work with it, fix it, whatever) suppose to conform to browser vendor's goals? They should not be allowed to tell working groups what should and should not be allowed! It is not up to them. If it is, what is the purpose of the working groups? Are the working groups composed only of browser vendors, or both designers/coders and browser vendors? Vendors should be made to follow the standards and codes, and ideas and goals of the working group, should they not? -- Brett P. On Tue, Jan 13, 2009 at 3:10 AM, olafbuddenha...@gmx.net wrote: Hi, On Fri, Jan 09, 2009 at
Re: [WSG] HTML 5 and XHTML 2 combined
On 20 Jan 2009, at 19:18, Brett Patterson wrote: I would feel everyone in cooperation would be the way to go. Browser vendors (going to call them vendors, for short) need to understand that just because they want what they want does not matter as much as what is needed. If a major change is needed and vendors do not want to follow along, then so be it. If every vendor's ideas differed in some respect, then every browser would become an Internet Explorer -type browser. One that does not follow suit with the way things ought to be, in IE's case, is. It should be said to them that whole fact, to save everyone the headache of trying to design for every different browser and what that browser supports/ does not support. Sorry, but it is a bit of a touchy subject, especially considering the amount of work that one has to put in with others to get EVERY browser to play with one good block of code. How do you imagine this could be reconciled? If you hijack HTML5 to effectively become XHTML2, browser vendors will just again come up with something different conforming to *their* goals. (HTML4.5 or whatever.) Their goals are not as important as what the whole idea of the Web is, and Tim Berners-Lee's/CERN's goals for the Web. Which is, as one major part (responsibility of advocates/vendors/anyone with any part of the Web), universal accessibility. When vendors design for their own goal(s), they are not living up to that responsibility; therefore, their points and concerns mean NOTHING, and can be dismissed without a split-second thought, when it comes to the working groups and what is deemed necessary to reach that goal of universal accessibility. Not wanting to get into an argument, but if that is the case, who is going to implement the new specs if the vendors point, concerns and goals mean nothing? If vendors don't get behind a spec and implement it then developers can't use it. The best specs are those that take everyones needs into account; users, developers, designers and browser vendors. And to Benjamin Hawkes-Lewis, to answer your earlier questions When you speak of browser vendors mixing old languages with the new, I'm not sure what you mean, or why it is a problem. The below also explains the above quote of your question. The problem is, that we need to drop what really is heavy and unnecessary luggage, (this luggage being what is not supported in XHTML 1.0 Transitional, at least by my view points). Rift-raft, as Philip said is, the baggage of earlier, arguably poorly thought out, standards. You mentioned creating Transitional and Strict document types, but it's unclear what user problems this would solve or how exactly it would help merge HTML5 and XHTML2. I meant this in the sense of the current X/HTML transitional and strict approaches, as in the reason they were developed rather than just a Strict or Transitional approach (not implementing both, in HTML and XHTML). It could help merge them and solve problems by identifying any conflicting parts of the Standards, any conflicts that you can see that might take place. Focus on the Code that goes into a web page first, you have a small portion of differences that can be resolved by dropping the luggage of earlier, poorly thought out standards. Why would combining HTML5 and XHTML2 would prevent browser developers inventing their own language features? This is best answered by reading the 3 previous posts from this one. What headache are you talking about? The headache stems from the different code necessary to force IE to play nicely and the different codes each browser has made especially for itself (understand the question above about inventing their own language features, where we completely ignore them). But, anyway, like I said, I read your links and can now agree with you. I was just trying to answer your previous questions, not stir up another argument. -- Brett P. On Tue, Jan 20, 2009 at 11:45 AM, Molte molt...@gmail.com wrote: Indeed they should. The problem just might be, that if the browser vendors do not like the language they can simply just avoid supporting it (just like going on a strike). And then what idea is there of a standard that is not supported or used? It's just a question about who has the power to decide the future of the Web. The browser vendors? the coders/developers? us? or just everyone in cooperation? 2009/1/20 Brett Patterson inspiron.patters...@gmail.com Okay, long time posted in this subject. I see where Benjamin is heading with his discussions, and I agree with him. Took me awhile to read and understand his links. But, Olaf, why are browser vendors allowed to choose what is right and wrong with HTML and XHTML, and coders are to play along, and the working groups that build upon HTML and XHTML (work with it, fix it, whatever) suppose to conform to browser vendor's
Re: [WSG] HTML 5 and XHTML 2 combined
On Wed, Jan 21, 2009 at 5:18 AM, Brett Patterson inspiron.patters...@gmail.com wrote: I would feel everyone in cooperation would be the way to go. Browser vendors (going to call them vendors, for short) need to understand that just because they want what they want does not matter as much as what is needed. If a major change is needed and vendors do not want to follow along, then so be it. If every vendor's ideas differed in some respect, then every browser would become an Internet Explorer -type browser. One that does not follow suit with the way things ought to be, in IE's case, is. It should be said to them that whole fact, to save everyone the headache of trying to design for every different browser and what that browser supports/does not support. Sorry, but it is a bit of a touchy subject, especially considering the amount of work that one has to put in with others to get *EVERY* browser to play with one good block of code. Brett, just on this point - maybe I am old and cynical, or have just seen too much... but universal social responsibility from browser vendors that manifests as total consistency? While very desirable, I am willing to bet that it does not occur in my lifetime. Cheers, Andrew -- --- Andrew Boyd http://uxcommunity.org -- User Experience Community http://uxbookclub.org -- connect, read, discuss *** 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
Thanks Benjamin. The only troubles we face with = XHTML 1.1 and = HTML5 is related to progressive enhancement. 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? 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... but just how accessible would that be to a vision impaired visitor with _javascript_ turned off? Thanks, Anthony. Benjamin Hawkes-Lewis wrote: 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] Validating (X)HTML + ARIA
2009/1/21 Anthony Ziebell anth...@fatpublisher.com.au: Someone mentioned using JavaScript to implement ARIA parameters. This is a good idea... but just how accessible would that be to a vision impaired visitor with JavaScript turned off? I think the idea behind it is that because you also have server-side validation in place (which causes a full screen-refresh, so screen readers known that something has changed anyway) then if the user has JavaScript turned off they still won't miss anything. Sure they won't get the ARIA stuff, but neither will they get the JavaScript DOM changes that made it necessary in the first place. That's my understanding, anyway... ~Seona. *** 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] Validating (X)HTML + ARIA
Oh, also... there is a requirement for our pages to validate (hence I can only see JavaScript as a valid option at this point?) Benjamin Hawkes-Lewis wrote: 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 *** *** 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 Wed, 21 Jan 2009 10:15:38 +1100, Anthony Ziebell wrote: Oh, also... there is a requirement for our pages to validate (hence I can only see JavaScript as a valid option at this point?) *Is* there a requirement for our pages to validate? I would have thought that making a page more accessible would be far more important. After all, Google sees fit to ignore validation in order to speed up page rendering - another worthwhile goal. I must say that I regard validation and spell-checking as equivalent (and equally important). If I use my U.S. spell-checker on a review of a book with the word colour in the title, should I change the spelling according to the spell-check's version - color? I think not. Cordially, David -- *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Microformats Accessibility
I think it's a clash between microformats VS html AND accessibility standards. On Mon, January 19, 2009 12:48 am, Ben Rowe wrote: 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 *** *** 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
Hi, Just tabbed through the page and the login form are the very last elements on the page to be hit, needs a lower tab-index, not very nice in terms of accessibility. cheers Luke Stewart Griffiths wrote: Harsh is fine, it's a critique / review we asked for ;o) Got rid of all but one error, which is a vb one, so will work on finding that. As for breaking when the text is increased, well, as you state this is due to the way vb spits out the code. But we can work on that going forward. WE will look at the typography we are using and look to make it consistent across the site, the background gradiants and the nav icons we will again look at updating. Thanks for the feedback, this is all great stuff. Stew 2009/1/16 Benjamin Hawkes-Lewis bhawkesle...@googlemail.com mailto:bhawkesle...@googlemail.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 mailto:memberh...@webstandardsgroup.org *** *** 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] Examples of great high-school websites?
Hi Alan Interesting that they justify layout tables on the basis that some users may have IE5, yet have a slow, graphics-heavy site which will take forever to load without a broadband connection. How many users I wonder have a screen width of more than 1024px plus IE5 plus broadband? Elizabeth Spiegel Web editing 0409 986 158 GPO Box 729, Hobart TAS 7001 www.spiegelweb.com.au From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Alan Berman Sent: Monday, 19 January 2009 12:29 PM To: wsg@webstandardsgroup.org Subject: 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 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_layouts http://en.wikipedia.org/wiki/Liquid_web_design 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
