Accessibility Minutes 2011 05 09
From MemberWiki
Contents |
Present
- 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
Caching
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.
aurelienlevy: http://www.w3.org/TR/EARL10-Schema/#OutcomeValue
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 ...
headers
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.
jongund: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-refs
aurelienlevy: http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/H81
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