Accessibility Minutes 2011 05 09

From MemberWiki

Jump to: navigation, search



  • Richard Schwerdtfeger (IBM - Co-Chair)
  • Jon Gunderson (University of Illinois - Co-Chair)
  • Marc Johlic (IBM)
  • Ann Abbott (IBM)
  • Nicholas Hoyt (University of Illinois)
  • Aurelien Levy (Temesis)
  • Vio Onut (IBM)

Response to the Steering Committee

Rich: IBM has a version of it in Policy Tester

Action: Rich send a note to Preety Kumar regarding OAA rules support

Action: Matt contact Nathan regarding OAA rules supppport

Jon: Aurelian is using the rule set in their product

Jon: We have 3 different technologies: AInspector - the accessibility inspector for Firefox, Illinois Functional accessibility evaluator 2.0, Accessibility extensions for Firefox

Jon: The students are developing extensions for Chrome and Safari

aurelienlevy: Opquast Reporting

Aurelian Levy: OpQuast Reporting is using the OAA rules

Vio: We are using the same rules format in Rational Policy Tester

Jon: We has unanimous support in the voting for our rules format (15-0)

Jon: any questions?

Ann: what happens next

Jon: the steering committee needs to vote when we say it is ready

Rich: I think we are need to fix our rules and performance

Rich: We need to freeze the 1.0 page


jongund: /member/wiki/Accessibility_DOM_Elements_Cache#Link_Elements_Cache

Jon: we need to add caching for performance

Jon: the DOM element base class has the DOM Nodes class

Jon: The cache is defined in document order

Jon: We will define where role="presentation" is applied

Jon: the aria-hidden attribute and the computed value of the display property must be stored in the base cache.

Jon: these are base attributes

Jon: this needs to be basic information about each object. The base class will be inherited by other caches

ann: Nicholas Hoyt from the University of Illinois is attending

Jon: If something is not displayed or is not intended to be exposed it impacts the testing

Jon: Rules passed and Rules failed are stored as arrays

Jon: We have an array of Rules conditions not met

Jon: If the calculated accessible name is unique on the page, and the link references each uniquely then we say the conditions are met.


Jon: A rule cannot be evaluated. .. This is the case where for obvious reasons cannot be tested. These would be manual checks

Rich: What about where sections are marked aria-busy?

Jon: this could be a reason as well but different than what I was thinking

Nick: what is the concept of busy?

Jon: when content is updated on the page you should not be looking at that part of the page as it is not ready and has incomplete information

Rich: If you mark a section as busy then you really can't test that part of the page

Jon: the node and all of its children

Rich: yes

Jon: this means you can't even apply rules. I need to think about it any more

Jon: so you would stop processing any descendants of that node

Rich: there should be some sort of warning as the entire document could not be analyzed as the nodes were marked busy at the time of the analysis

Jon: these locations should be flagged in the report.

ann: can't you loop back to see when it is not busy

Rich: you could repopulate the cache when it goes from busy to not busy

Jon: Let's think about that

Rich: You can monitor for state changes to repopulate the cache in response to aria-busy

Rich: I think it would be a problem if the flag never clears. If it never clears then we mark it as an error

Jon: I put a note in the cache page here

Jon: I will make a note in the cache

Links element cache

Jon: this takes the base class and add links to the cache

Jon: the first is the href reference

Jon: The first is text accessible name as seen by an assistive technology. this is important for manual test to make sure that the link text indicates the target of the link

Jon: the next is the text for comparison

Jon: for our unique link text, (wcag 2.44.or 2.46) for AAA requirements

element context

Jon: if the context is valid we can use this to calc. the ...


Jon: this includes headers, table headers, etc. to satisfy 2.44

Text from content property

Jon: this looks at landmark content with aria labelling

Text content from heading

Jon: looking at the last heading for this link

Jon: between these things the link will probably pass

Topic Context from Paragraph

Jon: separate paragraphs have different text they would pass 2.44 but not 2.46

Jon: there are more stringent requirements for AAA

Jon: If you use more in separate paragraphs and the text of each were different they would pass AA

Jon: It is very hard not to pass 2.44

Jon: A lot of people meet 2.44 by accident vs. design

Jon: 2.44 is A

Jon: 2.49 is AAA

Nick: So you would call this new property "content from sentence"

Rich: sentence gets difficult with eastern languages

Jon: we are giving people so many ways to satisfy this it frustrates me a bit

Jon: you should not provide the same link text to point to 2 different URLs

Aurelian: I have a comment on the cache. How are you testing the title attributes on the links?

Jon: I know working with AT users that looking for supplemental information i the title attribute is a problem

Jon: every time we implement a rule we create another problem

Aurelian: all these rules for testing the links should have a duration. ... you still will need to do a manual test for link purpose

Jon: providing the text and context text will facilitate manual tests. The more rules we implement context the more cluttered we get.



Jon: has there been any review of the link

Jon: Marc are the techniques for these sufficient. Do they stand by these?

Action: Marc test for context text is this accurate. Please ask the WCAG working group whether they stand by these techniques as being adequate.

Jon: G53 and H33 - please ask them to review these

Marc: H78 looks like G53

Jon: G53 separates out the sentences as having unique text

Jon: G53 this is if you are in the same list or paragraph

Jon: G53 is if you are in the same container where H78 is not

Jon: I think G53 and H33 should be removed as sufficient techniques - my opinion

Aurelian: Yes, sometime these can be used and other instances they can not. They are not useful

Aurlian: A with Context

Jon: 2.49 is AAA and I am surprised that it would not be in A

Jon: for now I would say that for the purpose of generating rules H76, 78, and 79 and a landmark technique would work. We should propose a landmark technique

Proposal: Do not provide a rule for H78 and G53 for now

Vio: no strong opinion. I am fine with that.

Jon: we can put them back if people complain

Jon: WCAG is already weak on creating accessible links

Jon: 2.44 is pretty wide open

Rich: I support leaving H78 and G53 out for now

Jon: for 2.49 they take out the paragraph one

Jon: you can satisfy 2.44 but not 2.49 with the title attribute

Jon: so we will just do the context we have now for element. The LI element will include the text from its parent LI element

Jon: A lot of people will include image text in a link. The screen reader will read the link text twice

Jon: if it is the same we can mark that as an error for 2.49

Jon: For things that are not in WCAG such interactive elements or links being too small to interact with that is a problem. We need to warn developers of that situation.

Jon: there is a resized text problem

Rich: the browser magnify everything with the correct aspect ration

Jon: it is advisory in 1.44 where the links are too small.

Jon: WCAG has nothing about this

Personal tools