Accessibility Minutes 2010 09 08
From MemberWiki
Present
- Rich Schwerdtfeger (IBM - Co-Chair)
- Jon Gunderson (Illinois - Co-Chair)
- David Todd (IBM)
- Marc Johlic (IBM)
- Nathan Jakubiak (Parasoft)
- Vio Onut (IBM)
- Sharon ? (?)
Minutes
Attending: Rich, David Todd, Jon, Marc, Nathan, Vio
http://openajax.org/pipermail/accessibility/2010-September/000378.html
Also attending: Sharon
RS: Have not heard back from Bertrand from Microsoft re: Working Group STatus and Charter Approval. Rich to contact Jon and Bertrand
JG: Agenda for next time: rule format change proposal
http://openajax-prod.jongund.webfactional.com/examples/
JG: Like to talk about the website
JG: Can reference external websites from this website. Would like feedback on some of summary info to collect for each example to make example searchable
JG: First col - unique id number for each example. Next col - description
JG: 6 cats for accessible name categorization
JG: could be important to show how accessible name computed
JG: first step was to get all our good examples up
JG: didn't want to go to test suites directly so people not confused
JG: major issue with using aria - if people go into high contrast mode aria selectors not shown
RS: need to have test cases for that
RS: aria-driven attribute selection as better name?
JG: Next col is HTML elements that are interesting. Next cols are aria roles and states - important for search
JG: left-hand bar gives menu that allows you to see examples based on category
JG: If you go to overview it organizes by roles
DT: under accessible name for child nodes, does that mean accessible name implied by child nodes?
JG: Yes, child nodes determine accessible name unless overridden by aria labeled by
DT: "implied" by child nodes might be better
JG: Don't have a good name if you didn't get it
JG: Child text nodes?
DT: Would work
JG: Rule submitters have to determine what aria properties roles they want to highlight
DT: Once we starting putting rules into DB, will the examples for them show up here?
JG: Examples not geared toward rules at this point
JG: You build a test case for a specific rule. But examples will be maintained separately. Because test suites will have something bad, don't want to mix that with good example
JG: Don't want people to have to sift through good and bad examples in a test suite
JG: Useful relationships between markup and rules and test suites. Examples just have relationship to markup
DT: Folks might be confused if looking through examples that have errors
JG: Could say "these are related rules to this example"
JG: Already has that capability, but is broken
JG: planning to have test suite part done by next time Next are Rule and Rule Sets sections on top
JG: How many people using rule set for testing right now?
JG: Nobody seems to be - is anybody at IBM? Want to talk about separating out type code and severity code
JG: Want to take out requirement vs. best practice and put in own category to make easier to sort so don't have to parse severity level
VO: have prototype at IBM using part of the rules
JG: severity currently is violation, potential violation, conditional manual check, manual check
VO: Potential violation meant could be a violation but unable to fully test it
JG: Potential violation and conditional manual check could be same thing
/member/wiki/Accessibility_-_WCAG20_Validation_Rules
JG: in FAE and FF tool conditional manual checks could go away if you use a particular coding practice
VO: wiki page has different set of names - are we using same semantics as at beginning
VO: afraid about adding new categories
JG: these are just proposals - trying to make sense of it myself
VO: Recommendation is what includes best practices - violations do not
VO: "possible" means cannot fully test for both violation and recommendation
VO: And then had manual test
JG: so you like it that way?
VO: open for changing.
JG: Could be easier to sort if separate out violation and recommendation
VO: need to separate out impl from semantics. If we all agree on semantics, impl should be simple
JG: Need to decide soon because need to produce spec soon
DT: Could see that as useful
VO: We are using the current levels - can change on our side if necessary
VO: Could separate the way it is now
VO: Although I never understood why have manual test category - since manual already included in other "potential" categories
JG: Potential violations in our tool meant there was better coding practice that made the potential violation go away
VO: Not in line with definition on wiki
JG: Some types of manual tests will never go away - no matter how you code it
JG: Conditional tests - don't need to test if feature not there
JG: language tests will always be a manual test
JG: Conditional manual test based on whether something there
JG: One of things we have that would call potential violation - have headings but text context not unique within that level
JG: I consider "potential violations" as something that could be fixed
http://html.cita.illinois.edu/nav/heading/heading-rules.php
RS: have to leave this call
VO: this example - is required or is best practice?
JG: probably considered best practice. Most people would probably say they are nice but not required
VO: these examples seem like a recommendation - if user has to check then it's a potential recommendation
JG: so you're saying these things are just recommendations - and "potentials" are manual tests
VO: right - never understood why have manual test
VO: if best practice and can fully test - recommendation. If cannot fully test, then is potential recommendation
JG: language changes - don't know if there is high probability or not - should we take out "high probability"
JG: probability may be main distinction between "potential" rules and manual test
VO: By using current levels - might be hard to only show best practices - because don't know for manual test
JG: Other input?
DT: Agree with Vio that manual test somewhat redundant?
Marc: Agree
NJ: Ever have case where always have to check regardless of what is on page?
JG: People design for testing engine - not for accessibility.
VO: If have to check on every page could be put into required or recommendation
JG: If "potential" categories are manual tests - then we're covered
NJ: Okay unless we have an example
NJ: we can remove manual test unless we have an example where we need it
RS: caching issues needs to be addressed
RS: if people agree can start working on coding it
RS: MS had proposal to cache certain things so don't have to traverse DOM every time
http://openajax.org/pipermail/accessibility/2010-August/000374.html
JG: How know when cache good to use?
DT: Looking at example, would pull info out of global cache and see if undefined
DT: left up to rule engine to clear things at right point
JG: is cache on rule by rule basis, or is there standard cache that rules can share?
JG: goal is to share cache between rules, right?
DT: Something to consider
RS: cache per rule is wasteful
JG: Should we define different caches?
JG: headers, form controls, widgets, etc.
JG: will need to be documented to be used in rules
DT: Can put a list together and send out to mailing list
RS: NJ do you see any cross-browser issues?
NJ: I would support caching
VO: CSUN call for papers out - another agenda item?