Nabble - w3.org - w3c-wai-ig

Portuguese Translations (was Re: Call for Review: Portuguese)

2009-12-18T05:46:10Z

Dear Cesar,

Thank you for your interest in translating WAI resources. We have a
number of Portuguese translations of WCAG 2.0 documents and other WAI
resources. Here is where you can find existing translations:

# WCAG 2.0 Translations (Portuguese section)
- <http://www.w3.org/WAI/WCAG20/translations#pt>

# Translations of WAI Documents (from the W3C Translations Database)
- <http://www.w3.org/2005/11/Translations/Query?wai=any>

Information about translating W3C resources is provided in:

# W3C Translations
- <http://www.w3.org/Consortium/Translation/>

# Translating WAI Documents
- <http://www.w3.org/WAI/translation>

Regards,
Shadi

Cesar Augusto Cusin wrote:

> Dear WAI Interest Group Participants,
>
>
>
> If you need help with the translation into Portuguese I'm available.
>
>
>
> Regards,
>
>
> ___________________________
>
> Cesar Augusto Cusin
> Doutorando em Ciência da Informação
> Mestre em Ciência da Computação
> Fone: +55 15 9135-1683
> Lattes: http://lattes.cnpq.br/3946561052824159
> Twitter: http://twitter.com/cesarcusin
>
>
> _________________________________________________________________
> Navegue com segurança com o Novo Internet Explorer 8. Baixe agora, é gratis!
> http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmail&utm_medium=Tagline&utm_content=Tag4&utm_campaign=IE8

--
Shadi Abou-Zahra - http://www.w3.org/People/shadi/ |
WAI International Program Office Activity Lead |
W3C Evaluation & Repair Tools Working Group Chair |

Call for Review: Portuguese

2009-12-18T02:24:28Z

Dear WAI Interest Group Participants,

If you need help with the translation into Portuguese I'm available.

Regards,

___________________________

Cesar Augusto Cusin

Doutorando em Ciência da Informação

Mestre em Ciência da Computação

Fone: +55 15 9135-1683

Lattes: http://lattes.cnpq.br/3946561052824159

Twitter: http://twitter.com/cesarcusin

Windows 7: agora com recursos que economizam bateria. Clique para conhecer.

Call for Review: Spanish WCAG 2.0 Candidate Authorized Translation

2009-12-17T09:22:20Z

Dear WAI Interest Group Participants,

W3C Web Accessibility Initiative (WAI) invites you to review the draft Spanish translation of Web Content Accessibility Guidelines (WCAG) 2.0:
Pautas de Accesibilidad para el Contenido Web (WCAG) 2.0
http://www.sidar.org/traducciones/wcag20/es/

Please send your comments in Spanish or English to:
public-auth-trans-es@...
by *29 January 2010*
Comments are publicly archived at http://lists.w3.org/Archives/Public/public-auth-trans-es/
You can subscribe to this list by sending an e-mail with the subject "subscribe" to: public-auth-trans-es-request@...

This draft translation is a "Candidate Authorized Translation" developed under the *Policy for Authorized W3C Translations*, which provides a process for stakeholder review and designation as an official translation, described at:
http://www.w3.org/2005/02/TranslationPolicy

WAI encourages the development of W3C Authorized Translations of WCAG 2.0 and other technical specifications to facilitate their adoption and implementation internationally. Completed and planned WCAG 2.0 translations are listed at:
http://www.w3.org/WAI/WCAG20/translations

Feel free to circulate this message to other lists; please avoid cross-postings where possible.

Regards,
Shawn Lawton Henry, W3C WAI Outreach Coordinator
Shadi Abou-Zahra, W3C WAI International Program Office Activity Lead

-----
Shawn Lawton Henry
W3C Web Accessibility Initiative (WAI)
e-mail: shawn@...
phone: +1.617.395.7664
about: http://www.w3.org/People/Shawn/

braille css support

2009-12-16T06:03:10Z

can someone point me to an overview of UA support for the css braille media type?

Thanks

Julian

This email has been scanned for all viruses by the MessageLabs EmailSecurity System on behalf of Eden District Council.For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com

Call for Review: WAI-ARIA Updated Working Drafts [link correction]

2009-12-16T04:54:00Z

[message re-sent with link correction]

Dear WAI Interest Group Participants,

The Protocols and Formats Working Group (PFWG) invites you to review the following updated Working Drafts published 15 December 2009:
* Accessible Rich Internet Applications (WAI-ARIA) 1.0
http://www.w3.org/TR/wai-aria/
* WAI-ARIA User Agent Implementation Guide
http://www.w3.org/TR/wai-aria-implementation/
* WAI-ARIA Authoring Practices
http://www.w3.org/TR/wai-aria-practices/

WAI-ARIA defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax (also known as AJAX), HTML, JavaScript, and related technologies.

The WAI-ARIA User Agent Implementation Guide provides guidance on how browsers and other user agents should expose WAI-ARIA features to platform accessibility APIs.

WAI-ARIA Authoring Practices describes how Web content developers can develop accessible rich internet applications using WAI-ARIA.

For an introduction to WAI-ARIA and links to related documents, please see:
* WAI-ARIA Overview http://www.w3.org/WAI/intro/aria
* WAI-ARIA FAQ http://www.w3.org/WAI/aria/faq

Note about Working Draft Status:
WAI-ARIA was published as a Last Call Working Draft on 24 February 2009. Due to substantial changes in response to comments on that draft, PFWG decided to return to Working Draft stage to collect feedback on these changes. The PFWG expects to publish another Last Call Working Draft in the first quarter of 2010. The development stages are described in:
* How WAI Develops Accessibility Guidelines through the W3C Process
http://www.w3.org/WAI/intro/w3c-process

WAI encourages you to review the updated WAI-ARIA documents and submit comments on any issues that you think could present a barrier to future adoption and implementation of WAI-ARIA. Please send comments per the instructions at:
http://www.w3.org/WAI/PF/comments/instructions
*by 2 February 2010*

Please let us know if you have any questions. Thank you in advance for your comments.
Feel free to circulate this message to other lists; please avoid cross-postings where possible.

Regards,
~Shawn Henry and Judy Brewer, W3C WAI
On behalf of:
Janina Sajka, Chair of PFWG
Michael Cooper, W3C WAI Staff Contact for PFWG

-----
Shawn Lawton Henry
W3C Web Accessibility Initiative (WAI)
e-mail: shawn@...
phone: +1.617.395.7664
about: http://www.w3.org/People/Shawn/

email clients and accessibility [SEC=UNCLASSIFIED]

2009-12-15T22:32:36Z

Hi,

I was wondering if anyone has any idea where I can find information on the
accessibility requirements for email clients.

Thanks,

Mary-Anne

Help the Starlight Foundation connect sick kids to the joy of Christmas - make a donation any Medicare office or visit www.starlight.org.au

______________________________________________________________________
********************************************************************************
NOTICE - This message is intended only for the use of the addressee named above and may contain privileged and confidential information. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action based upon it. If you received this message in error please notify Medicare Australia immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Medicare Australia.

Please consider the environment before printing this e-mail
***********************************************************************************

Call for Review: WAI-ARIA Updated Working Drafts

2009-12-15T11:27:41Z

Dear WAI Interest Group Participants,

The Protocols and Formats Working Group (PFWG) invites you to review the following updated Working Drafts published 15 December 2009:
* Accessible Rich Internet Applications (WAI-ARIA) 1.0
http://www.w3.org/TR/wai-aria
* WAI-ARIA User Agent Implementation Guide
http://www.w3.org/TR/wai-aria-implemention
* WAI-ARIA Best Practices
http://www.w3.org/TR/wai-aria-practices

WAI-ARIA defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax (also known as AJAX), HTML, JavaScript, and related technologies.

The WAI-ARIA User Agent Implementation Guide provides guidance on how browsers and other user agents should expose WAI-ARIA features to platform accessibility APIs.

WAI-ARIA Authoring Practices describes how Web content developers can develop accessible rich internet applications using WAI-ARIA.

For an introduction to WAI-ARIA and links to related documents, please see:
* WAI-ARIA Overview http://www.w3.org/WAI/intro/aria
* WAI-ARIA FAQ http://www.w3.org/WAI/aria/faq

Note about Working Draft Status:
WAI-ARIA was published as a Last Call Working Draft on 24 February 2009. Due to substantial changes in response to comments on that draft, PFWG decided to return to Working Draft stage to collect feedback on these changes. The PFWG expects to publish another Last Call Working Draft in the first quarter of 2010. The development stages are described in:
* How WAI Develops Accessibility Guidelines through the W3C Process
http://www.w3.org/WAI/intro/w3c-process

WAI encourages you to review the updated WAI-ARIA documents and submit comments on any issues that you think could present a barrier to future adoption and implementation of WAI-ARIA. Please send comments per the instructions at:
http://www.w3.org/WAI/PF/comments/instructions
*by 2 February 2010*

Please let us know if you have any questions. Thank you in advance for your comments.
Feel free to circulate this message to other lists; please avoid cross-postings where possible.

Regards,
~Shawn Henry and Judy Brewer, W3C WAI
On behalf of:
Janina Sajka, Chair of PFWG
Michael Cooper, W3C WAI Staff Contact for PFWG

-----
Shawn Lawton Henry
W3C Web Accessibility Initiative (WAI)
e-mail: shawn@...
phone: +1.617.395.7664
about: http://www.w3.org/People/Shawn/

CF Workshop Proposals - NDT 2010

2009-12-15T01:22:44Z

CALL FOR Workshop proposals and special sessions

Second International Conference on Networked Digital Technologies (NDT 2010)
Charles University, Prague, Czech Republic, July 6-8, 2010
http://www.dirf.org/ndt2010/
ndt@...

The Second International Conference on 'Networked Digital Technologies' (NDT2010) which will be held in Prague, Czech Republic during the period of July 6-8, 2010 seeks proposals for workshops or special sessions on cutting edge technology of networking. The website for the conference is www.dirf.org/ndt2010. This might include digital technology applications for the various disciplines. For the creation of research clusters, the research community has thousands of databases, websites, local computing clusters, and web-based tools around individual themes, interests and projects. In most cases, these tools and resources are and were created to meet the specific needs of a particular community. In many cases, the funding and support for these critical initiatives is fragile and temporary, and directed in piecemeal fashion. There is a need to provide concerted efforts in building federated digital technologies that will enable the formation of network of digital technologies. Topics might include, but not limited to :

Information and Data Management
Data and Network Mining
Intelligent Agent-Based Systems, Cognitive and Reactive Distributed AI Systems
Internet Modeling
User Interfaces, Visualization and Modeling
XML-Based Languages
Security and Access Control
Trust Models for Social Networks
Information Content Security
Mobile, Ad Hoc and Sensor Network Management
Web Services Architecture, Modeling and Design
New Architectures for Web-Based Social Networks
Semantic Web, Ontologies (Creation, Merging, Linking and Reconciliation)
Web Services Security
Quality of Service, Scalability and Performance
Self-Organizing Networks and Networked Systems
Data management in Mobile Peer-to-Peer Networks
Data Stream Processing in Mobile/Sensor Networks
Indexing and Query Processing for Moving Objects
User Interfaces and Usability Issues form Mobile Applications
Mobile Social Networks
Peer-to-Peer Social Networks
Sensor Networks and Social Sensing
Social Search
Social Networking Inspired Collaborative Computing
Information Propagation on Social Networks
Resource and Knowledge Discovery Using Social Networks
Measurement Studies of Actual Social Networks
Simulation Models for Social Networks
Cloud computing
Grid computing
Green Computing

For the workshop/special session proposal, the workshop should provide an informal and vibrant opportunity for researchers and industry practitioners to share their research positions, original research results and practical development experiences on specific new challenges and emerging issues.
The workshop/special session topic should be focused so that the Participants can benefit from interaction with each other and the cohesiveness of the topic.

The organizers and chairs of the workshop/special session shall have full control on the call for papers, forming of program committees, review and selection of papers as well as planning the workshop program. HOWEVER, the program committee chairs are not allowed to submit papers to the workshops for a fair review process. The registration fees for workshops/special session will be determined by the conference (not the workshop itself). The fees will be paid to the conference, and the conference will provide workshop facilities including the working notes printing, the meeting room, coffee break, lunch, proceedings and etc. Any further expense of the workshop such as financial aid for invited speakers MUST be provided by the workshop itself upon getting some sponsors for their own workshops. The money from workshop/special session sponsors will be received by the workshop itself.

After the workshops/special sessions, all the outstanding papers have the right to be included in special issue journals of the conference beside the proceedings. The workshop/special session chair must organize a review committee to select the outstanding papers from the papers presented in the workshop. Based on the reviews, each selected paper should be further improved for the camera ready version. Further details are available in the conference URL.

Prospective workshop/special sessions should send a proposal (maximum two pages) to the ndt@... which include the necessary information such as the title of the workshop/special session, objectives, scope, etc.

Note: The workshop should have at least 12 papers and the special session should have at least 6 papers.

We look forward to your proposals and contributions to NDT2010 workshops/special sessions.

Share Resources Supporting Web Accessibility Business Case

2009-12-14T08:05:03Z

Dear WAI Interest Group Participants,

The W3C WAI today published a collection of statistics, case studies, and articles supporting the business case for web accessibility in:
Resources for Developing a Web Accessibility Business Case for Your Organization
http://www.w3.org/WAI/bcase/resources.html

We are seeking more strong resources and cases studies. *Would your organization be willing to share your case study to support the business case for web accessibility*? If you have made accessibility improvements to your website in the last three years, we may be able to help you gather data and develop a case study.

To share business case resources, please e-mail the publicly archived list:
w3.org-wai-editors@...
Or: team-accessibility-business-case@... (This second mailing list is not publicly archived; however, there are some non-W3C-staff Working Group members subscribed to the list.)

See also:
Share Resources Supporting the Web Accessibility Business Case blog post
http://www.w3.org/QA/2009/12/share_resources_supporting_the.html

Please let us know if you have any questions or comments.

Feel free to circulate this message to other lists; please avoid cross-postings where possible.

Regards,
~Shawn Henry, Education and Outreach Working Group (EOWG) Chair

-----
Shawn Lawton Henry
W3C Web Accessibility Initiative (WAI)
e-mail: shawn@...
phone: +1.617.395.7664
about: http://www.w3.org/People/Shawn/

new articles on www.atechnews.com

2009-12-11T19:31:18Z

Hello,

I have new stories on www.atechnews.com that I think you will like.

As we approach Christmas, your thoughts are on buying gifts. For sports enthusiasts, click on the Let’s Play Football button on www.atechnews.com. . This is an excellent accessible game for individuals with disabilities. There is a 30% discount and shipping is free. Use this code mfg12 for the discount.

Also look at the Rob Mayben story and Luminaud button.

Thanks,

John Williams

Re: RGAA (was RE: @summary in the wild)

2009-12-10T17:09:55Z

On 10/12/2009 23:46, aurelien.levy@... wrote:
> summary attribut is requiered only for data table and we expect to change the guidelines to limit its use only on complex data table.
>
> RGAA will be frequently updated specialy when ARIA will become official recommandation, it's a suite of unit test to verify conformity to wcag 2.0 (specially needed by the public services to verify that the webagency is really doing her job correctly when the tender target a wcag compliant website)

Ah, j'ai trouvé les documents en question ;)
http://references.modernisation.gouv.fr/rgaa-accessibilite

So, if I understand it correctly, RGAA is a set of your own normative
tests, tied to specific technologies (doing things like mandating actual
attributes, like alt for images and summary for data tables), which you
then match up to WCAG 2.0 success criteria? It's basically a tightly
defined subset of possible techniques (as there may exist a theoretical
infinite number of techniques, as long as they pass the SC) that you
require authors to adhere to? I can understand the benefit of this for
large-scale conformance testing, but you're really then just testing
conformance to RGAA, not to WCAG 2.0 (as there are certainly other
techniques, not mandated in RGAA's test appendix of the WCAG 2.0
techniques document, which nonetheless pass the SC).

Sorry, not being difficult here, just making sure I understand the
purpose of RGAA (and to clarify that WCAG 2.0's original intent is not
to make any statements as to required or not required attributes...only
the SCs matter, and the techniques are merely informative).

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 | http://flickr.com/photos/redux/
______________________________________________________________
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
______________________________________________________________

AA Compliance Job

2009-12-10T07:18:20Z

Position: Application Developer – CSS / HTML / ASP

Reference SOL321

Location: Luton

Salary: Fixed Term Contract (3-6 months)

Responsibilities of the Role:

As an Application Developer – CSS / HTML / ASP for Stepstone you’ll be working alongside our existing development team to actively support our AA Compliance Project. You will be responsible for amending a wide range of existing customer web sites to ensure they meet with AA Compliance standards.

StepStone

StepStone has evolved from being a company with online job boards to one that provides total talent solutions. Providing talent management software and online services, we help organisations find, recruit, retain and manage talent. A strong network of partners brings together extensive industry knowledge and years of experience in Talent Management, guaranteeing effective, comprehensive solutions.

Your skills and qualifications as Application Developer – CSS / HTML / ASP will ideally include:

Proven experience with web development and web programming
Experience of using AA compliance testing tools a distinct advantage
Experience of Microsoft ASP, VB6 and VB.NET
A good understanding of CSS, (X)HTML and Javascript
SQL skills desirable but not essential
A desire to work in a customer focused technology team
English language skills to a business standard

What we will be looking for in you:

Ideally you’ll possess excellent communication skills, a positive attitude, and be able to contribute to the success of this project through your professionalism in dealing with colleagues and clients alike.

Contact:

To apply for this position please follow the link:

http://www11.i-grasp.com/fe/tpl_stepstone_01.asp?newms=jj&id=30131

--
Andrew Laws Bsc(Hons) MBCS, FBCS
Web-Sites:
www.opelnet.co.uk
www.cubiks.com
www.holidayhypermarket.co.uk
e-mail: adlaws@...
Telephone:: +44 (0) 7828822987

Re: Redesign Styles Hypocritical

2009-12-10T02:45:56Z

On 10/12/2009 10:38, Alan Gresley wrote:
> Patrick H. Lauke wrote:
>> - in Firefox, go to Tools > Options > Content > Advanced and set the
>> Minimum font size
> For http://www.w3.org/
>
> This is also the first page in a long time that I have encountered where
> my *font-size settings via tools in Firefox does not work*. I have to
> use zoom instead.

The above works for me in FX3.5.5. Set minimum to, say, 20, and the page
gets its text bumped up. Yes, there are a few bits of text that then
misalign/cut-off, but the functionality does act on the W3C page as well.

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 | http://flickr.com/photos/redux/
______________________________________________________________
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
______________________________________________________________

Re: Redesign Styles Hypocritical

2009-12-10T00:03:26Z

Patrick H. Lauke wrote:

> - in IE8, go to Tools > Internet Options > General > Accessibility >
> Ignore font sizes specified by webpages

Which used to cause many high profile sites to fail very badly and still
commonly results in some elements being hidden by overlaps.

(I haven't noticed the problem recently, but it also used to cause
overlapped text when people used absolute line heights, which was quite
common, including some pages generated by Microsoft proxies.)

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Re: Redesign Styles Hypocritical

2009-12-09T20:43:00Z

On 10/12/2009 03:10, Felix Miata wrote:
> On 2009/12/09 21:59 (GMT) Patrick H. Lauke composed:
>> Accessibility rarely deals with absolutes, black/white situations.
>
> That may be true, but without question for sighted users legibility is
> fundamental to accessibility. Since he isn't there, the designer has no
> reasonable basis to determine that making his baseline text size anything
> other than 100% can improve or maintain legibility.

So there are shades of legibility then. So again, not binary
accessible/inaccessible. Just ideal and not ideal?

>> Ok, this argument has been going around forever. It assumes that users
>> set their browser to their preferred font-size.
>
> To bring up this issue presumes a designer can or should do anything about
> what users do or don't do with their browser's default text size. Since the
> designer isn't there, he's in no position to determine the consequences
> outside his direct control, including whether a user needs or would rather
> something different than what he has. Thus it doesn't matter whether users
> know how or do or not. Any do, and they should be given deference.

The same could also be said for choice of colour, layout, ...

>> It also neglects the
>> fact that, for better or worse, the large majority of sites do (either
>> through px based fonts or something like font-size: 0.85em or whatever)
>> duck the standard body size from 100% on a regular basis.
>
> This paradigm has outlived its desirability.

"And still it moves". It may have outlived it, but it's still here in
the web as it is today.

>> As they have to on the majority of other sites out there. Either that or
>> *they* would have to go into their preferences and change the default
>> text size, which I'd posit not many people even know how to do.
>
> And I posit that most of those who actually _need_ to will find out both that
> they can, and how to do it.

Ok, so assuming that users _do_ change their settings...while they're
rummaging in preferences and settings, and they come across many (if not
most) sites that still do the less desirable thing of setting sizes in
pixels and/or below 100%, they would then also likely:

- in IE8, go to Tools > Internet Options > General > Accessibility >
Ignore font sizes specified by webpages
- in Firefox, go to Tools > Options > Content > Advanced and set the
Minimum font size
- (equivalent for other browsers)

?

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 | http://flickr.com/photos/redux/
______________________________________________________________
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
______________________________________________________________

Re: Redesign Styles Hypocritical

2009-12-09T19:10:22Z

On 2009/12/09 21:59 (GMT) Patrick H. Lauke composed:

> GÃ©rard Talbot wrote:

> Accessibility rarely deals with absolutes, black/white situations.

That may be true, but without question for sighted users legibility is
fundamental to accessibility. Since he isn't there, the designer has no
reasonable basis to determine that making his baseline text size anything
other than 100% can improve or maintain legibility.

>> It's utterly weak to tell web visitors/users that they should just zoom
>> the page themselves if they want to read it according to their eyesight
>> needs, legibility requirements, vision... when, from the beginning, all
>> the web author had to do is set body {font-size: 100%;} or body
>> {font-size: medium;} or not set any font-size at all for body so that
>> (s)he would meet the preferred font-size of the visitor.

> Ok, this argument has been going around forever. It assumes that users
> set their browser to their preferred font-size.

To bring up this issue presumes a designer can or should do anything about
what users do or don't do with their browser's default text size. Since the
designer isn't there, he's in no position to determine the consequences
outside his direct control, including whether a user needs or would rather
something different than what he has. Thus it doesn't matter whether users
know how or do or not. Any do, and they should be given deference.

Personal computer users who find it _necessary_ to change it will find out
how, either by trial, or by seeking help. If they can figure out how to
change desktop wallpaper, they can change text size. After all, they're
users' _personal_computers_, systems designed to be _personalized_.
Paternalism here is unjustified.

> It also neglects the
> fact that, for better or worse, the large majority of sites do (either
> through px based fonts or something like font-size: 0.85em or whatever)
> duck the standard body size from 100% on a regular basis.

This paradigm has outlived its desirability. Many years ago when display DPI
was considerably lower, and the range from lowest to highest much lower, it
wasn't unreasonable to assume 100% was too big. In the years since earnest
browser support for CSS began, average DPI has climbed considerably, as has
the range between lowest and highest. It's no longer reasonable to presume
100% is too high. It's now as likely to be too small as too big, and the
consequences of too small are usually more dire than those of too big.

> As they have to on the majority of other sites out there. Either that or
> *they* would have to go into their preferences and change the default
> text size, which I'd posit not many people even know how to do.

And I posit that most of those who actually _need_ to will find out both that
they can, and how to do it.

> Copying this to the WCAG list for their take (for those just joining us,
> the original thread is on W3C Style list, if I recall correctly)

I originated the thread on www-style (and site-comments, archived at
http://lists.w3.org/Archives/Public/www-style/2009Nov/0327.html ), with the
practical goal of having reconciled current W3.org site styles with the
content on http://www.w3.org/QA/Tips/font-size . Due to having forgotten I
had posted to both, my last follow up went only to www-style, is archived at
http://lists.w3.org/Archives/Public/www-style/2009Dec/0118.html and the
highlight of which is http://fm.no-ip.com/SS/SC/w3home-ss-0910.html to
demonstrate the impact of current styles in a high(er than average) DPI
environment.
--
" We have no government armed with power capable of
contending with human passions unbridled by morality and
religion." John Adams, 2nd US President

Team OS/2 ** Reg. Linux User #211409

Felix Miata *** http://fm.no-ip.com/

Re: Redesign Styles Hypocritical

2009-12-09T13:59:49Z

On 09/12/2009 20:48, Gérard Talbot wrote:
> my initial post was aimed at asking you to get involved into this W3C
> issue. It's not a trivial issue as it involves the official standard body
> on accessible content and official standard body on web related
> technologies. You signed your post in this thread as "Co-lead, Web
> Standards Project (WaSP) Accessibility Task Force
> http://webstandards.org/"

Which is not a standards body, official or otherwise, and has nothing to
do with the W3C directly.

> Let's explain this once for all.

Accessibility rarely deals with absolutes, black/white situations.

> When WCAG 2 states in G142
> http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G142
> exactly and precisely this:
> "
> G142: Using a technology that has commonly-available user agents that
> support zoom
> Applicability
> All technologies with user-agent provided zoom capability.
> (...)
> "
> then WCAG 2 in such G142 is out of its domain. G142 has nothing to do with
> Content Accessible; it has everything, every single word, from top to
> bottom, about User Agent Accessibility.
> http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G142

"Content authored in technologies that are supported by user agents that
can scale content uniformly"

The title of G142 is misleading and bad. But the description says
authors should use technologies (read CSS etc) that work with user
agents that are readily available and common (i.e. "accessibility
supported" http://www.w3.org/TR/WCAG/#accessibility-supporteddef)

> Anyone can verify my claim here.

I just did, and confirmed that the informative (rather than normative)
technique is badly titled and misleading in its shortened form, but that
the description - imho of course - clarifies it.

> If a sufficient criteria to achieve "1.4.4 Resize text" guideline is to
> use a graphical browser with a zoom feature

No it's not. It's "as an author, use a technology (like CSS) that also
works well in browsers that have zoom features, as this is an
accessibility-supported technology" or something to that effect.

> It's utterly weak to tell web visitors/users that they should just zoom
> the page themselves if they want to read it according to their eyesight
> needs, legibility requirements, vision... when, from the beginning, all
> the web author had to do is set body {font-size: 100%;} or body
> {font-size: medium;} or not set any font-size at all for body so that
> (s)he would meet the preferred font-size of the visitor.

Ok, this argument has been going around forever. It assumes that users
set their browser to their preferred font-size. It also neglects the
fact that, for better or worse, the large majority of sites do (either
through px based fonts or something like font-size: 0.85em or whatever)
duck the standard body size from 100% on a regular basis. As users
navigate not just your site, but a lot of others that do this, they will
likely have had to compensate for this somehow (bigger monitor, lowering
the resolution, using a screen magnifier, etc). Yes, in a perfect utopia
all sites would honour the 100%, all users would know how to change
their preferences accordingly (if they weren't buried 2-3 levels down in
the prefs), etc. But at least this W3C redesign stuck with what has
become a de-facto default size for most sites out there. Perfect? No.
Acceptable? Perhaps. Inaccessible? Arguably not, according to WCAG 2.

> How is the W3C stylesheet (with setting body {font-size: 13px} ... or to
> any smaller px-based value for that matter) meeting such "Additional
> Techniques (Advisory) for 1.4.4" ?

As they're advisory (and the whole of the techniques is only
informative, not normative), they chose to ignore them and stick with
the sufficient technique.

> In other words, if a font-size for unstyled body content is insufficient
> for people with low vision, over 40, over 50, with moderate eyesight lost,
> then *they* have to zoom the webpage

As they have to on the majority of other sites out there. Either that or
*they* would have to go into their preferences and change the default
text size, which I'd posit not many people even know how to do.

Copying this to the WCAG list for their take (for those just joining us,
the original thread is on W3C Style list, if I recall correctly)

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 | http://flickr.com/photos/redux/
______________________________________________________________
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
______________________________________________________________

Involve Users in Your Web Projects for Better, Easier Accessibility

2009-12-09T07:19:58Z

Dear WAI Interest Group Participants,

Want to better understand accessibility issues and implement more effective accessibility solutions?
The W3C WAI Web Accessibility Initiative (WAI) today published documents to help:
* Involving Users in Web Projects for Better, Easier Accessibility
http://www.w3.org/WAI/users/involving
* Involving Users in Evaluating Web Accessibility
http://www.w3.org/WAI/eval/users

The documents provide guidance on including real users, covering:
* How involving users early helps
* Finding a range of users
* Working with users
* Analyzing accessibility issues
* Drawing conclusions and reporting
* Note for usability professionals
* Combining user involvement with standards

We encourage project managers, designers, and developers of the following to read these documents:
* websites and web applications
* browsers, media players, and assistive technologies
* authoring tools such as content management systems (CMS), blog software, and WYSIWYG editors
* standards and policies on accessibility
* web technologies and technical specifications

See also the blog post:
* Discover new ways of thinking about accessibility
http://www.w3.org/QA/2009/12/discover_new_ways_of_thinking.html

These documents were developed and updated by Education and Outreach Working Group (EOWG) as part of the WAI-AGE Project. WAI-AGE is a European Commission IST Specific Support Action, with the goal of increasing accessibility of the Web for older people as well as for people with disabilities. See: http://www.w3.org/WAI/WAI-AGE/

Please let us know if you have any questions or suggestions.

Feel free to circulate this message to other lists; please avoid cross-postings where possible.

Regards,
~Shawn Henry, W3C WAI, EOWG Chair

-----
Shawn Lawton Henry
W3C Web Accessibility Initiative (WAI)
e-mail: shawn@...
phone: +1.617.395.7664
about: http://www.w3.org/People/Shawn/

Yesterday explained - THE FINAL EMAIL

2009-12-07T16:20:19Z

Hello, all on the list from yesterday.

This is the last email you will get from me, I just wanted to firstly say it was a mistake and secondly apologise for the email yesterday. That email was meant for a select group of friends.

To briefly explain what happened, I had a group in Gmail I had foolishly named "all MY contacts". For those who don't use Gmail, it automatically adds every single person you've ever emailed or replied to in a group called "all contacts". I chose the wrong group, emailing not only individuals, but lists too, sending that email out to God knows how many people.

To top it off, I added the list into CC, not BCC. I know how these things work, I just stuffed it. I don't do mass emails often.

After directly sending apologies to the first few hate mails, Gmail blocked me for exceeding my quota of emails for the day. I'd figured out what had happened by now, but all I could do after that was watch people keep clicking "reply all" to be removed, without being able to point out that wouldn't work. This quadrupled the hate mail...

I've changed the name of the list now and I've removed everyone who asked to be removed and/or I don't know from "all contacts". Although I'll probably need to do that again now thanks to Gmail.

Once again, I am really sorry, it's amazing how much mayhem can be caused with a few incorrect clicks. Unfortunately, emails can't be taken down once they're sent, like a blog post.

Apologies for any inconvenience,
Paul

Re: ARIA Project

2009-12-07T03:57:29Z

Hi,

At 05:20 7/12/2009, LU OGBE wrote:
>Hello,
>
>I am a Business IT student in my final year. I am thinking of doing
>a project on how screen readers such as JAWS behave with ARIA.
>Please can anyone give me advice on websites, mailing lists and
>online materials apart from the w3 where I can find useful material?
>Thanks in advance.

Maybe these links can get you started:
* Steve Faulkner: AJAX and Screen Readers - Content Access Issues (Feb 2008):
<http://www.paciellogroup.com/blog/?p=15>
* Steve Faulkner: Testing WAI-ARIA Role Support (Dec 2008):
<http://www.paciellogroup.com/blog/?p=100>
* Steve Faulkner: JAWS version 10 with WAI-ARIA live region support!
(Aug 2008):
<http://www.paciellogroup.com/blog/?p=89>
* Marco Zehe: The WAI-ARIA Windows screen reader shootout (July 2009):
<http://www.marcozehe.de/2009/07/01/the-wai-aria-windows-screen-reader-shootout/>
* Mozilla Developer Center: ARIA Screen Reader Implementors Guide
<https://developer.mozilla.org/En/ARIA_Screen_Reader_Implementors_Guide>
* Microsoft: Mapping ARIA Roles, States, and Properties to UI Automation
<http://msdn.microsoft.com/en-us/library/cc891505(VS.85).aspx>
* Free ARIA Community:
<http://groups.google.com/group/free-aria>
* Code Talks:
<http://wiki.codetalks.org/wiki/index.php/Main_Page>

Also, make sure that you understand what an accessibility API is and
why it is important.

Best regards,

Christophe

--
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
---
"Better products and services through end-user empowerment"
http://www.usem-net.eu/
---
Please don't invite me to LinkedIn, Facebook, Quechup or other
"social networks". You may have agreed to their "privacy policy", but
I haven't.

G'day from Copenhagen!

2009-12-07T03:28:57Z

Hi all,

I've decided to stop whinging about the lack of action on Climate Change and do something about it! I am currently in Copenhagen for the Climate Change Summit (COP15), which you've probably been hearing about.

There's a load of stuff going on behind the scenes that you won't get to see on the news, such as Klimaforum - a totally seperate people's forum, where anyone can attend. I've setup a Blog about these things, which I'll be updating dailly. http://climatechangestuff.com

I'm no expert on this stuff and there is so much technical jargon out there; the point of this trip is to learn more. The focus of the Blog is to document what I'm finding out and make the issues easy to understand.

Please take a look if you're interested in Climate Change & COP15. I don't want to annoy you with constant messaging if you're not though, so I've setup a Facebook page, if you subscribe here you can get updates: http://www.facebook.com/pages/Cozza/188288886599?v=wall

Or, you can sign-up for email updates on the right hand column of the site.

Or Twitter: http://twitter.com/cozzabags

Cheers, and and all the best.
Paul

ARIA Project

2009-12-06T20:20:13Z

Hello,

I am a Business IT student in my final year. I am thinking of doing a project on how screen readers such as JAWS behave with ARIA. Please can anyone give me advice on websites, mailing lists and online materials apart from the w3 where I can find useful material? Thanks in advance.

Regards,

Lu Ogbe

Bournemouth, UK

RE: More than one h1 tag

2009-12-02T08:14:59Z

TITLE is page-related meta data; it is not part of the page content. H1 is
part of page content and clearly visible as such. When a JAWS user views the
Heading List a clear relationship can be determined between H1 and other Hn
elements. It does not provide means to determine the same connection between
title and page headings.

Kind regards
Harry

~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~

---------- Original Message -----------
From: "Sonia" <sonia@...>
To: "'Harry Loots'" <harry.loots@...>, <w3c-wai-ig@...>,
<mwvirant@...>
Sent: Wed, 2 Dec 2009 14:11:02 -0000
Subject: RE: More than one h1 tag

> Wasn't Micheal's point that what you are deeming the role of the H1
> tag is actually the role of the Page Title?
>
> In relation to assistive technologies would this make sense?
>
> Thanks,
> Sonia
>
> Sonia Rockett
> SensoryStore
> 5 Barnfield Crescent
> Southernhay
> Exeter
> EX1 1QT
> www.sensorystore.co.uk
> Tel: 01392 495004
> Mob: 0796 816 3903
>
> "Accessible Design for Websites and Print"
>
> Please consider the environment before printing this email - thank you
>
> -----Original Message-----
> From: w3c-wai-ig-request@... [mailto:w3c-wai-ig-request@...]
> On Behalf Of Harry Loots Sent: 02 December 2009 09:17 To: w3c-wai-ig@...
> Subject: Re: More than one h1 tag
>
> Ironically, Michael, the point perhaps more clearly illustrates why there
> should be 1 H1 per page. A website is made up of a collection of
> webpages in the same way as a book is made up of chapters. The
> webpage is the chapter - it takes on the parent title (H1), and
> every other title (H2-H6) on this page
> (chapter) should relate directly to the parent title (H1), otherwise
> it should be better to split the page into multiple pages.
>
> Kind regards
> Harry
>
> ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~
>
> ---------- Original Message -----------
> From: Michael Virant <mwvirant@...>
> To: w3c-wai-ig@...
> Sent: Wed, 2 Dec 2009 13:15:04 +1100
> Subject: Re: More than one h1 tag
>
> > My view is that the web page TITLE is being conflated with the web page's
> > one or more H1 tags in this topic. Just as a book has one title it
> > typically has several chapters. Hence a web page should have one
> > title and as many H1 tags as is necessary to convey the same
> > structure. Then within in chapter (section with heading H1) there
> > may or may not be the need to order future sub headings (H2) all
> > related to the H1 above it.
> >
> > The alternative - to have only one H1 followed by one or more H2, H3
> > is disorientating for all users as it is an artificial
> > representation of the data. For example if the second section
> > (under a H2) of a document bears no relation to the first section
> > (with H1) then semantic markup forces the relationship of the second
> > section to be a child of the first section when there is no such
> elationship.
> >
> > Michael Virant
> ------- End of Original Message -------
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.426 / Virus Database: 270.14.89/2539 - Release Date: 12/01/09
> 19:32:00

------- End of Original Message -------

Re: More than one h1 tag

2009-12-02T08:08:01Z

This posting string was brought to my attention since there was a question about WCAG conformance at the start of it.

In all of these discussions, it is important to distinguish between what is good practice (or best practice) and what is required by WCAG 2.0

The original question was related to what is required for WCAG 2.0 conformance.

The answer to that question is that having only 1 H1 title on a page is not required by WCAG 2.0.

I will leave the best practice discussion to others -- since that is a broader question and relates both to general best practice and best practice for accessibility.

Regards

Gregg

-----------------------

Gregg Vanderheiden Ph.D.

Director Trace R&D Center

Professor Industrial & Systems Engineering

and Biomedical Engineering

University of Wisconsin-Madison

On Dec 2, 2009, at 9:39 AM, Richard_Userite wrote:

Hi Michael,
There is some logic in what you say, however the <title> element is not visible on the screen or printed page (except when presented at the top of the browser window) therefore it has become practice to use the <h1> element to repeat the <title> value, or at least a near interpretation of it. Thus the first (and only) <h1> IS the title of the page. This is not just an accessibility issue, the Google algorythm also compares the <title> and <h1> to aid scoring.

Semantically each page should have only one top level heading, it describes the purpose of the page. Different areas of the page should start with <h2> e.g. Navigation area, adverts etc. and, of course, subsections of the main text/content. Using this structure the <h2>s do bear a relationship with the original <h1> because they are on the same page, but - more importantly - if a blind user is on a second level heading anywhere in the page, and presses SHIFT/H in Jaws they will be taken to the top level heading, which they expect to be the main heading on the page (i.e. page title). If we have more than one <h1> then there is no single semantic structure to the page and the blind user will only be able to go back to the section heading not the main page heading.

If (God forbid) you are using Frames to construct your page there might be an argument for having an <h1> in each frame (as each frame is a stored as a seperate document), but we really should treat the web-page as it is presented to the user as a single document (regardless of how it is composed) and therefore ensure that there is only one top level heading on any one page.

Regards
Richard
www.userite.com

----- Original Message -----
From: mwvirant@...
To: w3c-wai-ig@...
Sent: Wednesday, December 02, 2009 2:15 AM
Subject: Re: More than one h1 tag

My view is that the web page TITLE is being conflated with the web page's one or more H1 tags in this topic. Just as a book has one title it typically has several chapters. Hence a web page should have one title and as many H1 tags as is necessary to convey the same structure. Then within in chapter (section with heading H1) there may or may not be the need to order future sub headings (H2) all related to the H1 above it.

The alternative - to have only one H1 followed by one or more H2, H3 is disorientating for all users as it is an artificial representation of the data. For example if the second section (under a H2) of a document bears no relation to the first section (with H1) then semantic markup forces the relationship of the second section to be a child of the first section when there is no such elationship.

Michael Virant

Re: More than one h1 tag

2009-12-02T07:39:39Z

Hi Michael,

There is some logic in what you say, however the <title> element is not visible on the screen or printed page (except when presented at the top of the browser window) therefore it has become practice to use the <h1> element to repeat the <title> value, or at least a near interpretation of it. Thus the first (and only) <h1> IS the title of the page. This is not just an accessibility issue, the Google algorythm also compares the <title> and <h1> to aid scoring.

Semantically each page should have only one top level heading, it describes the purpose of the page. Different areas of the page should start with <h2> e.g. Navigation area, adverts etc. and, of course, subsections of the main text/content. Using this structure the <h2>s do bear a relationship with the original <h1> because they are on the same page, but - more importantly - if a blind user is on a second level heading anywhere in the page, and presses SHIFT/H in Jaws they will be taken to the top level heading, which they expect to be the main heading on the page (i.e. page title). If we have more than one <h1> then there is no single semantic structure to the page and the blind user will only be able to go back to the section heading not the main page heading.

If (God forbid) you are using Frames to construct your page there might be an argument for having an <h1> in each frame (as each frame is a stored as a seperate document), but we really should treat the web-page as it is presented to the user as a single document (regardless of how it is composed) and therefore ensure that there is only one top level heading on any one page.

Regards

Richard

www.userite.com

----- Original Message -----

From: mwvirant@...

To: w3c-wai-ig@...

Sent: Wednesday, December 02, 2009 2:15 AM

Subject: Re: More than one h1 tag

My view is that the web page TITLE is being conflated with the web page's one or more H1 tags in this topic. Just as a book has one title it typically has several chapters. Hence a web page should have one title and as many H1 tags as is necessary to convey the same structure. Then within in chapter (section with heading H1) there may or may not be the need to order future sub headings (H2) all related to the H1 above it.

The alternative - to have only one H1 followed by one or more H2, H3 is disorientating for all users as it is an artificial representation of the data. For example if the second section (under a H2) of a document bears no relation to the first section (with H1) then semantic markup forces the relationship of the second section to be a child of the first section when there is no such elationship.

Michael Virant

Re: headings versus section headings

2009-12-02T07:37:03Z

Hi Bart,

At 16:24 2/12/2009, Bart Simons wrote:
>what is the difference between a heading and a section heading?
>
>SC 2.4.6 speaks about headings, whereas 2.4.10 speaks about section headings?
>
>Do both refer to different things or are these terms synonyms?

It is not a matter of different meanings but of different requirements:

SC 2.4.6 requires that headings describe the topic or purpose of the
relevant content, but not that headings are available. In other
words, *if* headings are available, they need to be descriptive.

SC 2.4.10 requires that headings are available for every section,
hence the term "section headings".

Best regards,

Christophe

--
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
---
"Better products and services through end-user empowerment"
http://www.usem-net.eu/
---
Please don't invite me to LinkedIn, Facebook, Quechup or other
"social networks". You may have agreed to their "privacy policy", but
I haven't.

headings versus section headings

2009-12-02T07:24:25Z

Hello,

what is the difference between a heading and a section heading?

SC 2.4.6 speaks about headings, whereas 2.4.10 speaks about section
headings?

Do both refer to different things or are these terms synonyms?

I'd like to know this for the translation of the WCAG2.0 document into
Dutch. Can we translate headings and section headings with the same term or
do we need to keep a difference?

Regards

Bart Simons
--
AnySurfer - Quality mark for accessible websites in Belgium
http://www.anysurfer.be

RE: More than one h1 tag

2009-12-02T06:11:02Z

Wasn't Micheal's point that what you are deeming the role of the H1 tag is
actually the role of the Page Title?

In relation to assistive technologies would this make sense?

Thanks,
Sonia

Sonia Rockett
SensoryStore
5 Barnfield Crescent
Southernhay
Exeter
EX1 1QT
www.sensorystore.co.uk
Tel: 01392 495004
Mob: 0796 816 3903

"Accessible Design for Websites and Print"

Please consider the environment before printing this email - thank you

-----Original Message-----
From: w3c-wai-ig-request@... [mailto:w3c-wai-ig-request@...] On Behalf
Of Harry Loots
Sent: 02 December 2009 09:17
To: w3c-wai-ig@...
Subject: Re: More than one h1 tag

Ironically, Michael, the point perhaps more clearly illustrates why there
should be 1 H1 per page. A website is made up of a collection of webpages in
the same way as a book is made up of chapters. The webpage is the chapter -
it
takes on the parent title (H1), and every other title (H2-H6) on this page
(chapter) should relate directly to the parent title (H1), otherwise it
should
be better to split the page into multiple pages.

Kind regards
Harry

~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~

---------- Original Message -----------
From: Michael Virant <mwvirant@...>
To: w3c-wai-ig@...
Sent: Wed, 2 Dec 2009 13:15:04 +1100
Subject: Re: More than one h1 tag

> My view is that the web page TITLE is being conflated with the web page's
> one or more H1 tags in this topic. Just as a book has one title it
> typically has several chapters. Hence a web page should have one
> title and as many H1 tags as is necessary to convey the same
> structure. Then within in chapter (section with heading H1) there
> may or may not be the need to order future sub headings (H2) all
> related to the H1 above it.
>
> The alternative - to have only one H1 followed by one or more H2, H3
> is disorientating for all users as it is an artificial
> representation of the data. For example if the second section
> (under a H2) of a document bears no relation to the first section
> (with H1) then semantic markup forces the relationship of the second
> section to be a child of the first section when there is no such

elationship.
>
> Michael Virant
------- End of Original Message -------

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.426 / Virus Database: 270.14.89/2539 - Release Date: 12/01/09
19:32:00

Re: More than one h1 tag

2009-12-02T01:16:43Z

Ironically, Michael, the point perhaps more clearly illustrates why there
should be 1 H1 per page. A website is made up of a collection of webpages in
the same way as a book is made up of chapters. The webpage is the chapter - it
takes on the parent title (H1), and every other title (H2-H6) on this page
(chapter) should relate directly to the parent title (H1), otherwise it should
be better to split the page into multiple pages.

Kind regards
Harry

~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~

---------- Original Message -----------
From: Michael Virant <mwvirant@...>
To: w3c-wai-ig@...
Sent: Wed, 2 Dec 2009 13:15:04 +1100
Subject: Re: More than one h1 tag

------- End of Original Message -------

Re: More than one h1 tag

2009-12-01T18:15:04Z

My view is that the web page TITLE is being conflated with the web page's one or more H1 tags in this topic. Just as a book has one title it typically has several chapters. Hence a web page should have one title and as many H1 tags as is necessary to convey the same structure. Then within in chapter (section with heading H1) there may or may not be the need to order future sub headings (H2) all related to the H1 above it.

The alternative - to have only one H1 followed by one or more H2, H3 is disorientating for all users as it is an artificial representation of the data. For example if the second section (under a H2) of a document bears no relation to the first section (with H1) then semantic markup forces the relationship of the second section to be a child of the first section when there is no such elationship.

Michael Virant

Re: More than one h1 tag

2009-12-01T00:33:45Z

I suspect having more than one H1 tag could disorientate screen reader
users as the convention from my understanding has been to create a
hierarchical tree structure out of a Web document. This is more of a
minor usability point and I'm not raising this as a key issue or
anything.

-peter

On Nov 30, 2009, at 3:41 PM, Jon Gunderson wrote:

> The use of the title and h1 element for titling a web page is a well
> known best practice for accessibility. I am interested in knowing
> of situations where more than one h1 would be considered a best
> practice for accessibility?
>
> iCITA HTML Best Practices Rules for Titling a web page:
> http://html.cita.illinois.edu/nav/title/title-rules.php
>
> NOTE: Up to two H1 elements are allowed as long as they follow the
> rules. One H1 could be used for web site information and the other
> for sub page information. The sub page information though is the
> most important use of the H1 element.
>
> And conformance tools to evaluate implementation of other best
> practices:
>
> Illinois Functional Accessibility Evaluator
> http://fae.cita.illinois.edu
>
> Firefox Accessibility Extension:
> https://addons.mozilla.org/en-US/firefox/addon/5809
>
> Jon
>
>
> ---- Original message ----
>> Date: Mon, 30 Nov 2009 13:33:33 +0100
>> From: "Harry Loots" <harry.loots@...>
>> Subject: RE: More than one h1 tag
>> To: Andrew Kirkpatrick <akirkpat@...>, WAI Interest Group
>> list <w3c-wai-ig@...>
>>
>> I'm in agreement with AWK - the specs do not forbid the use of
>> multiple <H1>s.
>> However, in practice it will make sense to only use one <H1> per
>> page - this
>> should describe the primary subject of the page - in the same way
>> as a printed
>> or Word-processed document would only have one top-level heading,
>> normally the
>> title of the document.
>> For what it's worth: I use <H2> to describe the page (including
>> primary /
>> secondary navigation / main content area title); and <H3> as the
>> paragraph or
>> section headings. Headings, properly nested, helps provide context to
>> speechreader users and allow them to quickly navigate around the
>> page, jumping
>> to different zones on the page, or jumping from one <H2> to the
>> next <H2>, etc.
>>
>> Now just to make sure that none of this discussion relains
>> relevant, we'll see
>> a brand new structure in XHTML 2/ HTML 5 when the H element will
>> assume the
>> characteristics of H1 or other Hn element based on it's position in
>> the
>> hierarchy of the document.
>>
>> Kind regards
>> Harry
>>
>> Mob: +44 7826 926 994
>>
>>
>> ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~
>>
>>
>> ---------- Original Message -----------
>> From: Andrew Kirkpatrick <akirkpat@...>
>> To: WAI Interest Group list <w3c-wai-ig@...>
>> Sent: Sun, 29 Nov 2009 16:48:36 -0800
>> Subject: RE: More than one h1 tag
>>
>>> I'd disagree with that statement - http://www.w3.org/TR/2008/NOTE-
>>> WCAG20-TECHS-20081211/G141.html indicates that authors _should_
>>> follow the structure you indicate, but nothing that says that they
>>> _must_. "Should" indicates that it is generally regarded as
>>> important, but if you are evaluating a site for WCAG 2.0 there is
>>> nothing in the recommendation that says that a page with three H1's
>>> would fail, provided that the page structure corresponds to that.
>>>
>>> Thanks,
>>> AWK
>>>
>>> Andrew Kirkpatrick
>>>
>>> Senior Product Manager, Accessibility
>>>
>>> Adobe Systems
>>>
>>> akirkpat@...<mailto:akirkpatrick@...>
>>>
>>> From: w3c-wai-ig-request@... [mailto:w3c-wai-ig-request@...]
>>> On Behalf Of Andy Laws Sent: Friday, November 27, 2009 11:22 AM To:
>>> WAI Interest Group list Subject: More than one h1 tag
>>>
>>> Dear All
>>> in the event of a page having more than 1 h1 tag can i confirm that
>>> this breaks guidling 1.3.1 of WCAG 2.0 as this not a meaningful
>>> sequence
>>>
>>> Reagrds
>>> Andy
>>>
>>> --
>>> Andrew Laws Bsc(Hons) MBCS, FBCS
>>> Web-Sites:
>>> www.opelnet.co.uk<http://www.opelnet.co.uk>
>>> www.cubiks.com<http://www.cubiks.com>
>>> www.holidayhypermarket.co.uk<http://www.holidayhypermarket.co.uk>
>>> e-mail: adlaws@...<mailto:adlaws@...>
>>> Telephone:: +44 (0) 7828822987
>> ------- End of Original Message -------
>>
>>
> Jon Gunderson, Ph.D.
> Coordinator Information Technology Accessibility
> Disability Resources and Educational Services
>
> Rehabilitation Education Center
> Room 86
> 1207 S. Oak Street
> Champaign, Illinois 61820
>
> Voice: (217) 244-5870
>
> WWW: http://www.cita.illinois.edu/
> WWW: https://netfiles.uiuc.edu/jongund/www/
>
> ---------------------------------------------------------------
> Privacy Information
> ---------------------------------------------------------------
> This email (including attachments) is covered by the Electronic
> Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and
> may be legally privileged. It is intended for the use of the
> individual or entity to which it is addressed and may contain
> information that is privileged, confidential, and exempt from
> disclosure under applicable law. If the reader of this email is not
> the intended recipient, or agent responsible for delivering or
> copying of this communication, you are hereby notified that any
> retention, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please reply to the sender that you have
> received the message in error, then delete it. Thank you.
>
>

Re: More than one h1 tag

2009-11-30T07:01:05Z

Its not that i disagree with anybody its just that we have in excess of 200+ web application to upgrade to AA compliance and a few customers have supplied templates with 2 h1 tags now we dont want to say to our clients that your site fails AA because of 2 h1 tags as opposed to advising that it is best practice only to have one h1 per page

<h1>Where I'm from</h1>
<h2>Earth</h2>
<h3>Europe</h3>

<h1>What I am</h1>
<h2>Primate</h2>
<h3>Mammal</h3>

On Mon, Nov 30, 2009 at 2:45 PM, Andrew Kirkpatrick <akirkpat@...> wrote:

The use of the title and h1 element for titling a web page is a well known best practice for accessibility. I am interested in knowing of situations where more than one h1 would be considered a best practice for accessibility?

I wouldn't say that it is a best practice, only that WCAG 2.0 does not specifically forbid it.
AWK

--
Andrew Laws Bsc(Hons) MBCS, FBCS
Web-Sites:
www.opelnet.co.uk
www.cubiks.com
www.holidayhypermarket.co.uk
e-mail: adlaws@...
Telephone:: +44 (0) 7828822987

RE: More than one h1 tag

2009-11-30T06:45:23Z

RE: More than one h1 tag

2009-11-30T06:41:15Z

The use of the title and h1 element for titling a web page is a well known best practice for accessibility. I am interested in knowing of situations where more than one h1 would be considered a best practice for accessibility?

iCITA HTML Best Practices Rules for Titling a web page:
http://html.cita.illinois.edu/nav/title/title-rules.php

NOTE: Up to two H1 elements are allowed as long as they follow the rules. One H1 could be used for web site information and the other for sub page information. The sub page information though is the most important use of the H1 element.

And conformance tools to evaluate implementation of other best practices:

Illinois Functional Accessibility Evaluator
http://fae.cita.illinois.edu

Firefox Accessibility Extension:
https://addons.mozilla.org/en-US/firefox/addon/5809

Jon

---- Original message ----

>Date: Mon, 30 Nov 2009 13:33:33 +0100
>From: "Harry Loots" <harry.loots@...>
>Subject: RE: More than one h1 tag
>To: Andrew Kirkpatrick <akirkpat@...>, WAI Interest Group list <w3c-wai-ig@...>
>
>I'm in agreement with AWK - the specs do not forbid the use of multiple <H1>s.
>However, in practice it will make sense to only use one <H1> per page - this
>should describe the primary subject of the page - in the same way as a printed
>or Word-processed document would only have one top-level heading, normally the
>title of the document.
>For what it's worth: I use <H2> to describe the page (including primary /
>secondary navigation / main content area title); and <H3> as the paragraph or
>section headings. Headings, properly nested, helps provide context to
>speechreader users and allow them to quickly navigate around the page, jumping
>to different zones on the page, or jumping from one <H2> to the next <H2>, etc.
>
>Now just to make sure that none of this discussion relains relevant, we'll see
>a brand new structure in XHTML 2/ HTML 5 when the H element will assume the
>characteristics of H1 or other Hn element based on it's position in the
>hierarchy of the document.
>
>Kind regards
>Harry
>
>Mob: +44 7826 926 994
>
>
>~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~
>
>
>---------- Original Message -----------
>From: Andrew Kirkpatrick <akirkpat@...>
>To: WAI Interest Group list <w3c-wai-ig@...>
>Sent: Sun, 29 Nov 2009 16:48:36 -0800
>Subject: RE: More than one h1 tag
>
>> I'd disagree with that statement - http://www.w3.org/TR/2008/NOTE-
>> WCAG20-TECHS-20081211/G141.html indicates that authors _should_
>> follow the structure you indicate, but nothing that says that they
>> _must_. "Should" indicates that it is generally regarded as
>> important, but if you are evaluating a site for WCAG 2.0 there is
>> nothing in the recommendation that says that a page with three H1's
>> would fail, provided that the page structure corresponds to that.
>>
>> Thanks,
>> AWK
>>
>> Andrew Kirkpatrick
>>
>> Senior Product Manager, Accessibility
>>
>> Adobe Systems
>>
>> akirkpat@...<mailto:akirkpatrick@...>
>>
>> From: w3c-wai-ig-request@... [mailto:w3c-wai-ig-request@...]
>> On Behalf Of Andy Laws Sent: Friday, November 27, 2009 11:22 AM To:
>> WAI Interest Group list Subject: More than one h1 tag
>>
>> Dear All
>> in the event of a page having more than 1 h1 tag can i confirm that
>> this breaks guidling 1.3.1 of WCAG 2.0 as this not a meaningful sequence
>>
>> Reagrds
>> Andy
>>
>> --
>> Andrew Laws Bsc(Hons) MBCS, FBCS
>> Web-Sites:
>> www.opelnet.co.uk<http://www.opelnet.co.uk>
>> www.cubiks.com<http://www.cubiks.com>
>> www.holidayhypermarket.co.uk<http://www.holidayhypermarket.co.uk>
>> e-mail: adlaws@...<mailto:adlaws@...>
>> Telephone:: +44 (0) 7828822987
>------- End of Original Message -------
>
>

Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61820

Voice: (217) 244-5870

WWW: http://www.cita.illinois.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/

---------------------------------------------------------------
Privacy Information
---------------------------------------------------------------
This email (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. It is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this email is not the intended recipient, or agent responsible for delivering or copying of this communication, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please reply to the sender that you have received the message in error, then delete it. Thank you.

RE: More than one h1 tag

2009-11-30T04:33:33Z

I'm in agreement with AWK - the specs do not forbid the use of multiple <H1>s.
However, in practice it will make sense to only use one <H1> per page - this
should describe the primary subject of the page - in the same way as a printed
or Word-processed document would only have one top-level heading, normally the
title of the document.
For what it's worth: I use <H2> to describe the page (including primary /
secondary navigation / main content area title); and <H3> as the paragraph or
section headings. Headings, properly nested, helps provide context to
speechreader users and allow them to quickly navigate around the page, jumping
to different zones on the page, or jumping from one <H2> to the next <H2>, etc.

Now just to make sure that none of this discussion relains relevant, we'll see
a brand new structure in XHTML 2/ HTML 5 when the H element will assume the
characteristics of H1 or other Hn element based on it's position in the
hierarchy of the document.

Kind regards
Harry

Mob: +44 7826 926 994

~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~

---------- Original Message -----------
From: Andrew Kirkpatrick <akirkpat@...>
To: WAI Interest Group list <w3c-wai-ig@...>
Sent: Sun, 29 Nov 2009 16:48:36 -0800
Subject: RE: More than one h1 tag

> I'd disagree with that statement - http://www.w3.org/TR/2008/NOTE-
> WCAG20-TECHS-20081211/G141.html indicates that authors _should_
> follow the structure you indicate, but nothing that says that they
> _must_. "Should" indicates that it is generally regarded as
> important, but if you are evaluating a site for WCAG 2.0 there is
> nothing in the recommendation that says that a page with three H1's
> would fail, provided that the page structure corresponds to that.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
>
> Senior Product Manager, Accessibility
>
> Adobe Systems
>
> akirkpat@...<mailto:akirkpatrick@...>
>
> From: w3c-wai-ig-request@... [mailto:w3c-wai-ig-request@...]
> On Behalf Of Andy Laws Sent: Friday, November 27, 2009 11:22 AM To:
> WAI Interest Group list Subject: More than one h1 tag
>
> Dear All
> in the event of a page having more than 1 h1 tag can i confirm that
> this breaks guidling 1.3.1 of WCAG 2.0 as this not a meaningful sequence
>
> Reagrds
> Andy
>
> --
> Andrew Laws Bsc(Hons) MBCS, FBCS
> Web-Sites:
> www.opelnet.co.uk<http://www.opelnet.co.uk>
> www.cubiks.com<http://www.cubiks.com>
> www.holidayhypermarket.co.uk<http://www.holidayhypermarket.co.uk>
> e-mail: adlaws@...<mailto:adlaws@...>
> Telephone:: +44 (0) 7828822987

------- End of Original Message -------