Accessibility Minutes 2010 09 08

From MemberWiki

Jump to: navigation, search

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?