Accessibility Minutes 2009 04 01

From MemberWiki

Jump to: navigation, search

Contents

Participants

  • Ann Abbott (IBM)
  • Jon Ferriaolo (IBM) - OAA Director
  • Jon Gunderson (University of Illinois)
  • Nathan Jakubiak (ParaSoft)
  • Preety Kumar (Deque)
  • Tony Salcedo (ParaSoft)
  • Michael Squillace (IBM)
  • Rich Schwerdtfeger (IBM - chair)
  • Derk Stegemann (FIT)
  • David Todd (IBM)

Minutes

Agenda


The use of Style

David Todd's Post

RS: David put a post on the list we should discuss

David: embedding style within HTML

David: WCAG is not clear on whether to include the style attribut or not

David: There is a debate in the WCAG on the use of the style attribute

JG: G140 talks about class attributes

David: They kind of imply not to use the style attribute

ACTION: Preety will check with the WCAG group regarding whether it is illegal to use embedded style

JG: I don't think people use the style attribute alot

David: Some IBM apps use style attribute alot

JF: Many IBM apps use CSS

RS: WCAG 2 is referring to the use of the style attribute, not using CLASS attribute

The Use of bold Tags

RS: Vio Onut's proposal

RS: If text is wrapped in bold tags, followed by a break, then trigger a warning for use of header, do not text decoration or color to indicate structure

RS: He wants to rewrite this, do not use BOLD unless there is the following markup, many examples

RS: There are a number of mechanisms

JG: I think we should look for heading structure than looking for problems in markup

Preety: I think what we are trying to do find places where they are overlooked a heading

Preety: We find this commonly

Preety: I am not sure of the BR

RS: We should just look for bold?

Preety: BOLD with other things and conditions, it could get complicated

Preety: Depends on how many words are in the BOLD

RS: It sounds like we need to flag something

Preety: They should not be using BOLD at all, but we are looking for possible headings

David: We should give general guidance about how to use or NOT use BOLD

RS: We need to have a section on the use of BOLD

RS: Can you update the section on the BOLD tag?

David: yes

ACTION: David update the wiki section on the use of BOLD

RS: reviewing current wiki entry, what do you mean about class?

RS: When the CLASS attribute includes a "heading" text

RS: Preety is that something that we should be looking for CLASS heading?

Preety: yes

The use of non-DOM API function functions for updating the DOM

RS: If INNNERHTML or other writes should ...

David: WCAG2 recommends using the standard DOM functions

JG: We could warn people, but it will be ignored

Preety: there are security issues

RS: we should tell people why, security aside

Preety: I am not sure structural markup is the concern

Preety: Using non-standard markup you can still create structural markup

David: I will look for why in WCAG

ACTION: David Define why the use of INNERHTML and other non-DOM calls for updating the DOM are an accessibility issue

jakubiak: http://www.w3.org/TR/WCAG-TECHS/SCR21.html

JG: You need to make sure rules make sense

Preety: I will check with the design team

David: This is a level A requirement

Layout and Data Tables

RS: Table markup of layout

RS: role="presentation" is important

JG: we have some huristics for data tables

Preety: It some times get murky when tables are being used for both layout and presentation

RS: David it will be ignored with accessibility API

RS: If you have a TH in the table, what is the significant

RS: If the role="presentation" there should not be any TH elements

RS: For AT everything disappears

Preety: We definitely need to test for layout, the difficulty is mixed use

Preety: then we tell people to split things into 2 tables

RS: If you do any of this stuff you know you have a violation, other stuff gets more difficult

RS: The next one is do we want to enumerate some of the other stuff, is this other stuff trade secrets?

RS: Should we put in the obvious ones?

Preety: Yes, a 1x1

JonGund: University of Illinois Data Table Rules

JG: Our previous table rules were related to nesting

Preety: What about SCOPE?

JG: We did not find any examples where SCHOPE made any difference, but send me some if you have examples

RS: I suggest: If we detect a TD or ROLE=COLUMNHEADER there is not an adequate number of these that we flag an error, with the author needs to determine if it is a data table or a layout table and use the proper markup for that table

JG: I agree

RS: We can help the author with using ARIA presentation

Preety: I think we need a good sample set, before we can determine

RS: I will put in a note about creating a sample set

RS: Suggest using ARIA or HTML markup to data tables and ARIA markup for presentation tables

RS: We can create test cases

Check for Summaries in data tables

RS: Generate an error when a data table is missing a summary attribute

RS: Can you use aria-describedby?

RS: This is what HTML5 group has not decided yet

RS: The summary attribute can be misused

RS: I don't know if summary will be deprecated in the HTML5 or not

RS: Is aria-describedby better than summary?

Preety: yes, AT support is the primary reason

RS: We need to have some rules, link to iCITA rules

David: Is summary compatible with IE 7?

RS: This comes down to AT support, one major AT developer uses the DOM, not accessibility APIs for IE

RS: On Safari they use the accessibility APIs operat on the DOM structure

David: If tables automatically announce when table gets focus, describedby needs extra keystrokes

JG: aria-labelledby seems more like summary

JG: Summary seems like it has a mixed usage, it is used for both short and long

Preety: the caption element is used by ATs and automatically read for data tables

David: JAWS will read aria-describedby with F1

Preety: JAWS reads both the caption and the summary attribute

Use of Captions

RS: Do we want rules for captions?

David: Caption is not mandatory, and it must be in the caption element

Preety: If a data the caption must be present

David: I had the same impression for along time, then I read the requirement

JG: I will check the best practices group

ACTION JG: Add examples to wiki for summary and possibly captions

Progress on Rules Modeling Tool

RS: Michael you are developing a tool, we now run it as a standalone, we are trying to embed it as an applet, FF3 support, make it more flexible for people to use

Mike: What format are the rules going to take?

Mike: I sent a sample to this to the group

RS: I will check with Victor at Yahoo about YSlow people

Mike: For this group we do not want to be YSlow specific

JG: I think that there is a more general rule development with the YSlow people

JG: Meeting this Friday with the YSlow people