Accessibility Minutes 2011 07 11

From MemberWiki

Jump to: navigation, search

Present

  • Jon Gunderson (University of Illinois - Co-Chair)
  • Ann Abbott (IBM)
  • David Todd (IBM)
  • Rich Schwerdtfeger (IBM)
  • Marc Johlic (IBM)
  • Nicholas Hoyt - (University of Illinios) - scribe
  • Vio Onut (IBM)

OAA Accessibility inspector

Jon: HTML5 working group: they're working through emails which is not always an efficient process

Jon: Our issues: the WCAG techniques document

Jon: Will try to create an ARIA subgroup to focus on ARIA and HTML5

Jon: Need to find out who the WCAG and HTML5 editors are

Ann: Attendance seems to have dropped in this WG

Jon: Could be due to performance issues which are being worked on

Jon: Now, even for large pages, e.g. CNN.com, with cache runs in a few milliseconds

Jon: We're getting pretty close to being able to demo the performance updates and additional information

Jon: If you share the same link text, cache will tell you here are the other links with same text

Jon: Have been working on some code this morning but didn't quite get done, but next week we'll have an API to run the ruleset

Jon: Pass in DOM, ruleset and language, and it will create an evaluation object including logging with performance info

Jon: The logging keeps us on track with meeting performance goals

Jon: Goes thru the DOM just once and run all of the rules

Jon: Base object called DOMElement, and also specific DOM cache lists for links, headings, forms, tables, etc

Jon: DOM object also has computed style property, with foreground and background colors

Jon: Can do this hierarchically, so that inheritance is taken into account

David: Do you update the cache whenever something changes?

Jon: We don't currently have any triggers, also UI events can be used (when new list is displayed)

Jon: Investigating other possibility for triggering off of dynamic content events

Jon: Currently using small Java application (written by Nick) that uses HTMLUnit and can run ruleset and output results

Jon: Developing testbed: one on the server using HTMLUnit and one in the browser using FIrefox and Firebug extension

Jon: Triggering can by default be based on a timer, e.g. every four seconds, or on every page load

Jon: On tool by tool basis, triggering may need to be done differently

Jon: Fundamental to all of this is good performance

Rich: Do we now ask some of our inactive members to rejoin the teleconferences?

Jon: We're pretty close, but lets wait just a bit

Jon: Running multiple platforms hopefully will facilitate this

Vio: When you say update the cache, is that based on whether elements are valid?

Jon: We just go through the DOM once and collect various types of information

Jon: DOMElement is the basic information container, collected for all elements

Jon: The cache will enable us to know things such as whether an element is visible; at this point its just collecting data

Jon: Then we go through and run the rules, and cache is configures to make sure that rules run efficiently

Jon: With large page, 500-600 millisecond to update cache

Jon: Then each rule is run in about 1 millisecond

Jon: So 200 rules -> 200 ms.

Jon: Will have much richer info about each DOM node

Jon: DOMElement will keep track of which rules passed, potential violation failed, etc.

Jon: NLS file will also be a lot richer, since it can provide info based on this feedback

Jon: Two ways to get results: 1. from a requirements standpoint, find all nodes that passed, failed, etc.

Jon: And 2. from DOM node standpoint

Vio: Is there any concern about the size of the cache, e.g., when you're working with DOM, the information is there but it's not necessarily expanded

Vio: If you expand this info in the cache, will that cause problems?

Rich: Are you updating cache for every rule?

Jon: No, just with each update of cache, and running an individual rule takes about 1 msec.

Rich: In the past, just running an individual rule took a long time

Vio: One suggestion would be (I definitely see value of cache) but if we want to make sure this doesn't blow up (memory problems) maybe we can set a limit so that you stop using cache and you have to then compute on as needed basis

Vio: Would be surprising if these types of problems did not develop

Vio: In actual deployment there will be pages that will break this

Jon: Perhaps we put a node limitation, e.g. 3000 nodes

Vio: As long as we can put some type of limitation, then you can avoid crashes from exceeding memory

Vio: So we always use the cache, but utilize the node limit or whatever

Jon: Current evaluation object could start at an arbitrary DOM node

Jon: Should make this a design parameter; is there a way in JavaScript to find out memory usage?

Jon: Will have more info on all of this next week

Jon: Will then update the Wiki

Jon: Another issue: shifting our work back to rules

Jon: I put out there proposed landmark rules for navigation bars

jongund 4. 2. Proposed Navigation Landmark rules for navigation bars in web pages

jongund 1. Use UL/LI elements as containers for navigation links

jongund 2. Use nested lists for hide/show menus

jongund 3. Do not use role=navigation on the UL/LI elements, place role navigation on a DIV element containing the UL/LI elements

jongund 4. A DIV with role=navigation should not have any descendants with role=*

jongund 5. If there is more than one navigation landmarks, each navigation landmark should have a label

Jon: We found that people were putting landmarks on UL elements, but that overrides other information for UL (e.g. how many list items it contains)

Jon: Nested lists, use UL/LI/UL structure

Jon: With dynamic menus, were putting role=navigation on each sublist

Jon: with one main list and four sublists, they had a total of five role=navigation

Jon: An analogy is with headings where people went overboard by adding too many heading elements on a page

Jon: If nested properly, the list navigation commands provided by screen readers allow you to navigate the sublists

Jon: Either add role=navigation to all sublists and NOT on the list that contains them or only on the contains

Rich: We have notion of required children; what we can do is you can do the same thing for HTML list items LI

Rich: If your parent does not have a computed role of LIST then you have a failure

Rich: The problem that's been encountered is that the list structure have been broken

Jon: One other general rule: for any landmark role, it should not have a child with the same landmark

Jon: If you have a main, it cannot contain another "main"

Jon: Also, cannot have a "banner" inside a "banner"

Rich: Here's an example: a mashup and this part of page is the main content, its an iframe, and it loads another page which also has a main

Rich: What we've been pushing is having unique labels whenever you have nesting of landmarks

Rich: Current version of JAWS allows you to bring up hierarchical list of landmarks

Ann: Shortcut is CTRL-INSERT-SEMICOLON

Ann: As long as they have unique labels, it would make sense, esp. in portal portlet scenario

Jon: Two different scenarios: users who can understand this, and the user who is just going through document in a linear fashion

Jon: For hierarchical navigation bar, for submenus, would you want to have hierarchical landmarks

Jon: On a web page, these menus are not like menus in an application, they're just lists of links (nested)

Jon: If they're not making tab panels, and using nested lists, should submenus also have role=navigation?

Jon: So with pulldown menus, and web standards people say use nested unordered lists; so they're putting role=navigation at top level and also putting role=navigation on each nested list

Jon: Would it be best to have a total of 5 role=navigation as above, or better to use aria-labeled-by to give accessible name, either on top level container or on each of the sublists

Rich: One of the things we're following, if you're going to have two landmarks with the same role you would need to label them

Jon: The big question: What do developers do?

Jon: Developers can find a coding pattern that satisfies the rule but does not improve a11y

Jon: Especially when developers don't understand the requirement

Ann: At IBM, any time there's a page where same landmark is used more than once, they must have unique labels

Jon: Will do some testing of pages to see which patterns make the most sense

Jon: Thanks for CTRL-INSERT-SEMICOLON tip

Ann: I think it was introduced in JAWS 12

Jon: Next week would like to talk about WCAG 2.4.4 techniques

Marc: I'm going to take your suggestions to WCAG WG

Jon: I also applied to join WCAG techniques group

Jon: I'm glad they're refocusing their attention on techniques

annabbott Call ended at 1:00pm Central