From laura.lee.carlson at gmail.com Thu Jan 1 04:07:04 2009 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Thu, 1 Jan 2009 06:07:04 -0600 Subject: [html4all] Sam Ruby Blog Post: approach to raised issues Message-ID: <1c8dbcaa0901010407m3ec8a3f1w914acd43a6dd7672@mail.gmail.com> Thanks for Volunteering! By Sam Ruby "...I don't yet fully know what I can accomplish as co-chair of the HTML working group, but I do intend to approach every raised issue with a disarmingly simple question: Is this something you intend to work on?..." http://intertwingly.net/blog/2008/12/31/Thanks-for-Volunteering -- Laura L. Carlson From rob at robburns.com Thu Jan 8 11:30:42 2009 From: rob at robburns.com (Robert J Burns) Date: Thu, 8 Jan 2009 13:30:42 -0600 Subject: [html4all] HTML4All HTML (at http://html4all.org/wiki/index.php/HTML) Message-ID: Hello 4All, I've been adding much summary information to the HTML page I started on the HTML4All wiki [1]. The page content has grown substantially, but I want it to be a quick stop to find this summary information and then provide more detailed information in: 1) separate wiki pages for each module 2) separate HTML4All HTML recommendation prose sections 3) DTD (this is for better backwards compatibility with existing UAs that handle DTDs) 4) other schema definitions for better forward compatibility (XSD, RelaxNG, etc.) The main objective in providing these schema definitions (lowercase 's' and 'd') is to give authors a way to check their conformance against the machine checkable portion of the recommendation. We might break this main page into parts eventually also. I welcome anyone else to get involved with the editing. I've tried to follow all of the conversations of this group and the HTML WG, but I likely missed entire proposals and threads. I think at this stage we should be collecting together all of the proposals and only decide if or how to pare them down once we can look at all of the features side-by- side. Another improvement we can make over the WhatWG black-hole approach to deciding these matters. Following the HTML5 draft, I expect to focus most of my attention on two chapters: 1) "Semantics and Structure of HTML Documents" and 2) "The Elements of HTML". I want to do that in a way that as much as possible is serialization independent. However, unlike the HTML5 draft, it is not my goal to sweep under the rug the deficiencies in text/html. So whenever we simply cannot support a feature in text/ html, I will clearly state that, but don't want to therefore drop it from the XML (or any other) serialization. There are other topics that have been raised here that do not relate specifically to the vocabulary of HTML that I think might be worth getting their own chapter, but they are lower priority in mind view. Some of these other chapters might include: 1) HTML over email 2) HTML visual editing 3) HTML accessibility guidelines 4) Interactive web browsing UAs 5) Common DOM interfaces (and also interfaces for document, window, node, etc.) A few things to note about this exercise. Backwards Compatibility: It is remarkable that WhatWG ever claimed XHTML2 is not backwards compatible. There are far fewer proposals in XHTML2 that break backwards compatibility than those in HTML5 (aside form the text/html verses XML serialization issue, but if that's all they mean they should say so). Even the XHTML2 approach to globalize attributes would be much better adopted for the text/html serialization where newly introduced elements (as opposed to attributes) automatically break backwards compatibility. Another thing I notice from putting all of these features in one place is that WebForms can be made to work much more like XForms (while still being backwards compatible with legacy HTML forms) and XForms can be handled in text/html by adding new elements, using existing HTML elements with new attributes and providing a new LINK rel type to the XForms back-end content model that cannot be handled in the HEAD element in legacy UAs. Attribute Globalization: On another topic, I note two of the, likely, more controversial pieces in this HTML specification: ? globalization of the href attribute providing activated hypertext linking on any arbitrary element ? globalization of the src attribute providing embedding on any arbitrary element (though this does provide better alt text capabilities within the text/html serialization) I will be working to add these capabilities, as well as the others, to the open source rendering engines. They do not really degrade too gracefully in legacy browsers (depending on what the author wants to accomplish), but in the long-run we could be targeting only browsers that handled the features just fine. Namespaces: Adding default xmlns and xmlns:* declarations on the root HTML element ensures that many namespaces can be used with prefix only, easing the migration by authors to namespace aware documents. This means in HTML4All document could simply include the following:

some content ...

among other things. This makes the most common uses of namespace extensibility quite easy for authors to use and understand. There may be other namespaces we should include default prefixes for, that have slipped my mind. Of course in the short run, authors may need to add those prefix to namespace URI mappings manually for legacy support (including in the peculiar ways IE requires prior to IE8), but again our children will never have to deal with these complications. Adoption While embracing W3C recommendations is radical enough compared to the WhatWG approach to try to dumb down HTML, the actual backwards compatibility issues involved with HTML4All introduced elements are small indeed. The HTML4All HTML introduces about as many new elements (10) as it recommends WhatWG not introduce (10). However in every case except one (SUBTEXT), these elements degrade gracefully in non- supporting browsers. In other words they provide nice new features for authors and users in supporting browsers but they are perfectly usable on their own (without wrapping them in other elements or adding scripting functionality) in non-supporting UAs. The one exception ? the SUBTEXT element ? would require a delayed adoption by authors or the use of a DIV or SPAN element wrapped around the SUBTEXT element (and some author provided CSS) until IE support materialized (which is the only browser where it won't work today with CSS alone). The other proposals that have been made (and I have tried to track them all) do not involve new elements and so they degrade gracefully on their own. It is also remarkable that when one approaches the enhancement of HTML from authors' and users' needs rather than implementors' needs, most of the changes WhatWG proposes simply don't make the cut (and the proposals WhatWG cuts are the features authors and users need; though the FIGURE element does stand out as an exception and an excellent new WhatWG proposed element meeting the needs of authors and users). This is only focussing on HTML4all originating proposals. There are adoption issues with other newly proposed elements for text/html serializations: in particular the XForms, HTML5/WhatWG, and XHTML2 proposed elements. These have far greater problems than the HTML4All proposed elements in terms of correct and consistent parsing in legacy browsers using the text/html serialization. The introduction of namespaces might address this problem by, for example, introducing XForms as a namespaced extension to HTML for proper parsing in IE (plugins already exist once it is parsed correctly). I include the prefix 'x' as a default XForms prefix so that any XForms element can be included for proper namespaced parsing such as x:select1. Other transitional options exist (such as the proposal for a legacy- bridging interim markup[2]). While the differences between WhatWG HTML and HTML4All are small in the actual number of elements and attributes introduced into the vocabulary, the benefits for authors and users (including disabled users) are immense. Next Steps: I plan to get these summaries linked up with other pages in the coming weeks to provide more detail. For those of you who have been following these discussions over the last few years, you might already be familiar enough with these proposals to make sense of it from the summary alone. While many of these proposals have been authored largely by only a few of us, many other HTML4All members have been involved in the conversations that shaped the proposals (on this list, on the public list, within the HTML WG and in many private conversations). So I think of this as very much a group effort. My main focus will be on the pars of HTML that differ from HTML5 (data module, phonetic attributes module, mandatory alt and role, etc.). This includes the specification of a DTD and other schema definitions for HTML. It might even be worthwhile to rework Henri's open source conformance checker to work with HTML4All's HTML. Incidentally the specification of a real DTD means also that HTML4All HTML also solves the XSLT DocType problem that has consumed unwarranted debate within the HTMLWG, though authors would also be free to use the when the specificity was unnecessary. I think we have it in our power to produce this specification and make at least one UA (or even a few) work for our specification. Whether the World adopts what we do here is not up to us and we can't really do anything about that: anymore than the HTML WG or WhatWG can control it for their recommendations. As I'm sure many of us share the same outlook, what I think we want is an HTML that we can make use of in our own communities. If that's usable on the world wide web than all the better. But if it only works correctly in the best of breed browsers and degrades gracefully in all of the others than that's OK too (from my point of view, at least). Take care, Rob [1]: [2]: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at robburns.com Thu Jan 8 11:30:42 2009 From: rob at robburns.com (Robert J Burns) Date: Thu, 8 Jan 2009 13:30:42 -0600 Subject: [html4all] HTML4All HTML (at http://html4all.org/wiki/index.php/HTML) Message-ID: Hello 4All, I've been adding much summary information to the HTML page I started on the HTML4All wiki [1]. The page content has grown substantially, but I want it to be a quick stop to find this summary information and then provide more detailed information in: 1) separate wiki pages for each module 2) separate HTML4All HTML recommendation prose sections 3) DTD (this is for better backwards compatibility with existing UAs that handle DTDs) 4) other schema definitions for better forward compatibility (XSD, RelaxNG, etc.) The main objective in providing these schema definitions (lowercase 's' and 'd') is to give authors a way to check their conformance against the machine checkable portion of the recommendation. We might break this main page into parts eventually also. I welcome anyone else to get involved with the editing. I've tried to follow all of the conversations of this group and the HTML WG, but I likely missed entire proposals and threads. I think at this stage we should be collecting together all of the proposals and only decide if or how to pare them down once we can look at all of the features side-by- side. Another improvement we can make over the WhatWG black-hole approach to deciding these matters. Following the HTML5 draft, I expect to focus most of my attention on two chapters: 1) "Semantics and Structure of HTML Documents" and 2) "The Elements of HTML". I want to do that in a way that as much as possible is serialization independent. However, unlike the HTML5 draft, it is not my goal to sweep under the rug the deficiencies in text/html. So whenever we simply cannot support a feature in text/ html, I will clearly state that, but don't want to therefore drop it from the XML (or any other) serialization. There are other topics that have been raised here that do not relate specifically to the vocabulary of HTML that I think might be worth getting their own chapter, but they are lower priority in mind view. Some of these other chapters might include: 1) HTML over email 2) HTML visual editing 3) HTML accessibility guidelines 4) Interactive web browsing UAs 5) Common DOM interfaces (and also interfaces for document, window, node, etc.) A few things to note about this exercise. Backwards Compatibility: It is remarkable that WhatWG ever claimed XHTML2 is not backwards compatible. There are far fewer proposals in XHTML2 that break backwards compatibility than those in HTML5 (aside form the text/html verses XML serialization issue, but if that's all they mean they should say so). Even the XHTML2 approach to globalize attributes would be much better adopted for the text/html serialization where newly introduced elements (as opposed to attributes) automatically break backwards compatibility. Another thing I notice from putting all of these features in one place is that WebForms can be made to work much more like XForms (while still being backwards compatible with legacy HTML forms) and XForms can be handled in text/html by adding new elements, using existing HTML elements with new attributes and providing a new LINK rel type to the XForms back-end content model that cannot be handled in the HEAD element in legacy UAs. Attribute Globalization: On another topic, I note two of the, likely, more controversial pieces in this HTML specification: ? globalization of the href attribute providing activated hypertext linking on any arbitrary element ? globalization of the src attribute providing embedding on any arbitrary element (though this does provide better alt text capabilities within the text/html serialization) I will be working to add these capabilities, as well as the others, to the open source rendering engines. They do not really degrade too gracefully in legacy browsers (depending on what the author wants to accomplish), but in the long-run we could be targeting only browsers that handled the features just fine. Namespaces: Adding default xmlns and xmlns:* declarations on the root HTML element ensures that many namespaces can be used with prefix only, easing the migration by authors to namespace aware documents. This means in HTML4All document could simply include the following:

some content ...

among other things. This makes the most common uses of namespace extensibility quite easy for authors to use and understand. There may be other namespaces we should include default prefixes for, that have slipped my mind. Of course in the short run, authors may need to add those prefix to namespace URI mappings manually for legacy support (including in the peculiar ways IE requires prior to IE8), but again our children will never have to deal with these complications. Adoption While embracing W3C recommendations is radical enough compared to the WhatWG approach to try to dumb down HTML, the actual backwards compatibility issues involved with HTML4All introduced elements are small indeed. The HTML4All HTML introduces about as many new elements (10) as it recommends WhatWG not introduce (10). However in every case except one (SUBTEXT), these elements degrade gracefully in non- supporting browsers. In other words they provide nice new features for authors and users in supporting browsers but they are perfectly usable on their own (without wrapping them in other elements or adding scripting functionality) in non-supporting UAs. The one exception ? the SUBTEXT element ? would require a delayed adoption by authors or the use of a DIV or SPAN element wrapped around the SUBTEXT element (and some author provided CSS) until IE support materialized (which is the only browser where it won't work today with CSS alone). The other proposals that have been made (and I have tried to track them all) do not involve new elements and so they degrade gracefully on their own. It is also remarkable that when one approaches the enhancement of HTML from authors' and users' needs rather than implementors' needs, most of the changes WhatWG proposes simply don't make the cut (and the proposals WhatWG cuts are the features authors and users need; though the FIGURE element does stand out as an exception and an excellent new WhatWG proposed element meeting the needs of authors and users). This is only focussing on HTML4all originating proposals. There are adoption issues with other newly proposed elements for text/html serializations: in particular the XForms, HTML5/WhatWG, and XHTML2 proposed elements. These have far greater problems than the HTML4All proposed elements in terms of correct and consistent parsing in legacy browsers using the text/html serialization. The introduction of namespaces might address this problem by, for example, introducing XForms as a namespaced extension to HTML for proper parsing in IE (plugins already exist once it is parsed correctly). I include the prefix 'x' as a default XForms prefix so that any XForms element can be included for proper namespaced parsing such as x:select1. Other transitional options exist (such as the proposal for a legacy- bridging interim markup[2]). While the differences between WhatWG HTML and HTML4All are small in the actual number of elements and attributes introduced into the vocabulary, the benefits for authors and users (including disabled users) are immense. Next Steps: I plan to get these summaries linked up with other pages in the coming weeks to provide more detail. For those of you who have been following these discussions over the last few years, you might already be familiar enough with these proposals to make sense of it from the summary alone. While many of these proposals have been authored largely by only a few of us, many other HTML4All members have been involved in the conversations that shaped the proposals (on this list, on the public list, within the HTML WG and in many private conversations). So I think of this as very much a group effort. My main focus will be on the pars of HTML that differ from HTML5 (data module, phonetic attributes module, mandatory alt and role, etc.). This includes the specification of a DTD and other schema definitions for HTML. It might even be worthwhile to rework Henri's open source conformance checker to work with HTML4All's HTML. Incidentally the specification of a real DTD means also that HTML4All HTML also solves the XSLT DocType problem that has consumed unwarranted debate within the HTMLWG, though authors would also be free to use the when the specificity was unnecessary. I think we have it in our power to produce this specification and make at least one UA (or even a few) work for our specification. Whether the World adopts what we do here is not up to us and we can't really do anything about that: anymore than the HTML WG or WhatWG can control it for their recommendations. As I'm sure many of us share the same outlook, what I think we want is an HTML that we can make use of in our own communities. If that's usable on the world wide web than all the better. But if it only works correctly in the best of breed browsers and degrades gracefully in all of the others than that's OK too (from my point of view, at least). Take care, Rob [1]: [2]: -------------- next part -------------- An HTML attachment was scrubbed... URL: From foliot at wats.ca Thu Jan 8 16:21:12 2009 From: foliot at wats.ca (John Foliot - WATS.ca) Date: Thu, 8 Jan 2009 16:21:12 -0800 Subject: [html4all] HTML4All HTML (at http://html4all.org/wiki/index.php/HTML) In-Reply-To: References: Message-ID: <019301c971f0$2dcfc290$896f47b0$@ca> Robert J Burns wrote: > > Hello 4All, > > I've been adding much summary information to the HTML page > I started on the HTML4All wiki [1] Rob, This is simply an awesome amount of research, tracking and work you have done, and I want to publicly commend you for the effort. A quick review confirms that I personally will want/need to spend some time and attention to a fuller groking of your contributions/analysis/recap (already I note no mention of microformats - should they be considered here?), but the sheer effort to assemble all of this is impressive. Bravo friend! The obvious next question is: now what? While recipients of your email such as myself are now aware of this work, what are your thoughts moving forward? Internal discussion aside, how do you envision making these counter-proposals to some long-held WHAT-WG thinking more public? (group discussion encouraged) But again Rob, bravo for work extremely well done! JF From joshue.oconnor at cfit.ie Fri Jan 9 03:14:25 2009 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Fri, 09 Jan 2009 11:14:25 +0000 Subject: [html4all] HTML4All HTML (at http://html4all.org/wiki/index.php/HTML) In-Reply-To: References: Message-ID: <49673191.4010407@cfit.ie> Hi Robert, While I certainly commend your work, I am unsure whether it is a good idea to try to create "our" HTML. I think it would be a waste of time. In truth, much of my involvement in the WG has already felt like this. So once bitten twice shy. However, full kudos for effort and enthusiasm but I also think as Chaals pointed out without the W3C imprimatur it wont amount to anything. Unless you come up with some really hot ideas that the ivory tower of the WHATWG will absorb, and their operational modus is capricious at best. At the very least it's certainly worth discussion and you have done a _lot_ of work here which is to be commended, so well done. I am so busy I would just not have the time for such detailed spec analysis, on top of my current detailed spec analysis ;-) Cheers Josh From lhs at malform.no Sat Jan 10 08:00:50 2009 From: lhs at malform.no (Leif Halvard Silli) Date: Sat, 10 Jan 2009 17:00:50 +0100 Subject: [html4all] HTML4All HTML (at http://html4all.org/wiki/index.php/HTML) In-Reply-To: References: Message-ID: <4968C632.6010007@malform.no> Robert J Burns 2009-01-08 20.30: > Hello 4All, > [1]: Hi, I don't know if it is your invention or if I just overlooked that someone else used it, but the abbreviation THTML for text/html is a brillant one. I really think we could need that abbreviation in the "official" vocabulary, in order to properly discern between the vocabulary and the serialisation. Btw, since you reference the proposed markup for poetry etc, perhaps you want to consider Olaf Hoffman's draft for the Literature Markup Language? See: http://hoffmann.bplaced.net/lml -- leif halvard sili From rob at robburns.com Sat Jan 10 08:29:00 2009 From: rob at robburns.com (Robert J Burns) Date: Sat, 10 Jan 2009 10:29:00 -0600 Subject: [html4all] HTML4All HTML (at http://html4all.org/wiki/index.php/HTML) In-Reply-To: <4968C632.6010007@malform.no> References: <4968C632.6010007@malform.no> Message-ID: Hi Leif, Thanks. I thought it was a good idea to differentiate them as well. I wrote to Ian about that a long time ago and I think he thought it was a dumb idea. I've actually changed it a little to be tHTML with a lower case 't', though there may be places on the wiki where I have not done that yet. I've started that on the bug reports page[1]. Once one starts thinking about the serialization as a separate concept entirely it really helps a lot. I've recently learned there are many efforts to create binary serializations of XML infosets (such as EXI) [2]. The tHTML serialization ends up crippled compared to basically any other. With a DTD, we'll basically have the following serializations with no other work: 1. tHTML 2. XML 3. SGML 4. EXI[2] (and any other binary representation of the XML infoset) However, the tHTML serialization will not support the richer content models of the other serializations (such as tree tables, block quotations, tables and lists within paragraphs, etc). Thanks for the link on poetry. I think that's a vocabulary that probably should be part of the core HTML document format. Take care, Rob [1]: [2]: On Jan 10, 2009, at 10:00 AM, Leif Halvard Silli wrote: > Robert J Burns 2009-01-08 20.30: >> Hello 4All, > >> [1]: > > Hi, > > I don't know if it is your invention or if I just overlooked that > someone else used it, but the abbreviation THTML for text/html is a > brillant one. I really think we could need that abbreviation in the > "official" vocabulary, in order to properly discern between the > vocabulary and the serialisation. > > Btw, since you reference the proposed markup for poetry etc, perhaps > you want to consider Olaf Hoffman's draft for the Literature Markup > Language? See: http://hoffmann.bplaced.net/lml > -- > leif halvard sili > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > Archives: http://html4all.org/mailman/private/list_html4all.org/ From laura.lee.carlson at gmail.com Thu Jan 22 12:22:09 2009 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Thu, 22 Jan 2009 14:22:09 -0600 Subject: [html4all] alt Survey/Commets Message-ID: <1c8dbcaa0901221222l3d7d3cpb9ddf9ef4d509360@mail.gmail.com> Should alt be required for the img element in HTML5? Why or why not? Gez Lemon is doing an alt twitter survey / taking comments for a position paper on whether the alt attribute should be required for the img element in HTML5. He wants to be sure to considered both sides of the debate and is interested in hearing opinions. If you twitter and would like to respond please use the hashtag #althtml5. http://twitter.com/gezlemon/status/1139666244 Alternatively comment here. Thanks. Best Regards, Laura -- Laura L. Carlson From lhs at malform.no Sat Jan 24 16:24:08 2009 From: lhs at malform.no (Leif Halvard Silli) Date: Sun, 25 Jan 2009 01:24:08 +0100 Subject: [html4all] alt Survey/Commets In-Reply-To: <1c8dbcaa0901221222l3d7d3cpb9ddf9ef4d509360@mail.gmail.com> References: <1c8dbcaa0901221222l3d7d3cpb9ddf9ef4d509360@mail.gmail.com> Message-ID: <497BB128.4040303@malform.no> Laura Carlson 2009-01-22 21.22: > Should alt be required for the img element in HTML5? Why or why not? > Gez Lemon is doing an alt twitter survey / taking comments for a > position paper [...] > Alternatively comment here. PURPOSE OF @ALT: * required architecture for caring for non-visual users. * No @alt = technical invalidity. * Incorrect @alt content = lacking care for non-visual users. PURPOSE OF * Purpose is unaffected by @alt, lack of @alt or @alt content. * Content of @src or @alt reveal - but do not express - purpose. * Expressing purpose would require extra attribute. E.g. @role. * "Signficant content" cannot be expressed by (lack of) @alt. Lack of @alt would at best function as a content repair trigger. VALIDATION * @alt content unvalidatable for a HTML validator. * Exception: with @role="decoration", non-empty @alt = checkable. * HTML 5 should focus on the need for separate WCAG validation. * Warning: If e.g. role"photography" would make code invalid unless alt="non-empty", authors could start to fake alt-content. However, a warning which advices for correct @alt text, and against fake @alt text, could perhaps work. @DESCRIBEDBY and ALT TO ALT="CONTENT"? * @aria-describedby, @longdesc and
permit empty alt. * When @alt is empty due to e.g @describedby, then it would be handy if the UA could use the value of the @role attribute when it talks to the user about what the is. Example: For , UA could talk about as "photography" instead of as "the image". REPAIRING CONTENT * Content repair = different from display of @alt text. * Value of @role could be used for content repair when @alt is lacking *as well as* and when the @alt is empty. * @role="decorative" = potential for repair of non-empty @alt. * Even if @role="decorative", the @alt still should be empty. AUTHORING * no @role + correct @alt = better than incorr. alt + OK @role. * Minimum solution on photo sites: . Valid HTML. Invalid according to WCAG. BACKWARD COMPATIBILITY * UAs and not semantics = reason for *always* requiring @alt. LIMITATIONS OF IMG * WCAG recommends the use of the right element for the task. should be recommened for some cases. Summary: HTML 5 have sofar tried to put more functions into @alt (lack of @alt included). That only makes it harder to use. Instead, its purposes should be narrowed down. -- Leif Halvard Silli From laura.lee.carlson at gmail.com Sun Jan 25 03:46:30 2009 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Sun, 25 Jan 2009 05:46:30 -0600 Subject: [html4all] alt Survey/Comments Message-ID: <1c8dbcaa0901250346s3f0886dbk7fe97fa731e6dbe2@mail.gmail.com> Hi Leif, >> Alternatively comment here. > > PURPOSE OF @ALT [snip] Thank you very much for your thoughtful response. Much appreciated. You can track realtime Twitter comments at: http://search.twitter.com/search?q=althtml5 Best Regards, Laura -- Laura L. Carlson From lhs at malform.no Sun Jan 25 05:25:22 2009 From: lhs at malform.no (Leif Halvard Silli) Date: Sun, 25 Jan 2009 14:25:22 +0100 Subject: [html4all] alt Survey/Commets In-Reply-To: <497BB128.4040303@malform.no> References: <1c8dbcaa0901221222l3d7d3cpb9ddf9ef4d509360@mail.gmail.com> <497BB128.4040303@malform.no> Message-ID: <497C6842.1090809@malform.no> Leif Halvard Silli 2009-01-25 01.24: > Laura Carlson 2009-01-22 21.22: >> Should alt be required for the img element in HTML5? Why or why not? >> Gez Lemon is doing an alt twitter survey / taking comments for a >> position paper [...] > >> Alternatively comment here. One more comment: [ ... snip ...] > AUTHORING > * no @role + correct @alt = better than incorr. alt + OK @role. > * Minimum solution on photo sites: src="file" >. Valid HTML. Invalid according to WCAG. * When using the "minimum solution", it is recommended - for backward compatibility - to *exactly* repeat the value of @role inside @alt: photography I thought you might be amused (in the ironic sense) by this e-mail from Phoenix Holidays. I don't think they can have many blind or partially-sighted customers :-( ** Phil. --------

 



--
We hope you have enjoyed this update from Phoenix Holidays. If you do not want to receive any more newsletters, please click this link