Meeting minutes
<elguerrero> I can scribe for the next hour
Announcements and introductions
alastairc: announcements and introductions: Mike - Moving on from IBM at the end of December. New role is not a member of W3C. Will transition off WCAG2ICT Taskforce.
<CarrieH> congratulations Mike...
<Jennie_Delisi> Congratulations Mike! Really appreciated all the interactions so far. Hoping to continue!
Alastair: Looking for another facilitator for the WCAG2ICT Taskforce. Members of Taskforce consider being a facilitator; contact AGWG co-chairs. About 10 members, which is a good size. Open count is ~500.
<bbailey> +1 to Jennie_Delisi sentiments !
<SydneyColeman> present SydneyColeman
<julierawe> Congrats, mbgower!
mike: Hit open 500 count as milestone; low commit; advocating for people to join. Lots of opportunities for various roles in WCAG 2 Backlog.
Steve: Joining from Google; first meeting in AGWG.
<bbailey> s/roles in WCAG2ICT/roles in WCAG2-Issues (aka, backlog)/
Alastair: AG WG sticks with IRC to coordinate speaking order and notes
Jeremy: First time joining from Deque
<GreggVan> An early Thanks Mike ! in case I miss it later this month. Good luck in your new job -- and hope to have you back soon. Would really miss you,
<alastairc> https://
Alastair: December 16 will be the last meeting of the calendar year. Keep an eye on agenda page.
alastairc: Expect email communications
Sub-group participation https://www.w3.org/wbs/35422/AGWGSubgroupParticipation_Jan_26/
Rachael: New member meeting introductions are 30 minutes before the start of AGWG the first Tuesday of the month
<bbailey> From survey, subgroups are: Image and media alternatives subgroup
<bbailey> Text and wording subgroup
<bbailey> Input and focus, interactive components subgroup
<bbailey> Errors, task completion and help subgroup
<bbailey> User orientation, layout and structure subgroup
<bbailey> User control, prevent harm subgroup
<bbailey> Single sense and contrast subgroup
<bbailey> Sign language subgroup
<bbailey> Conformance subgroup
alastairc: Agenda item - sub-group participation. URL https://
Starting in January, there's a 8-week stretch of work targeted to be done.
… wanting reasonable participation in each sub-group. If interested in multiple sub-groups, say yes, and add a comment about the limit of your time commitment. Two steps: What are you interested in? Are you interested in co-leading? Editing group leads and co-leads needed.
<tayef> is there documentation describing each subgroup?
<SydneyColeman> how do we submit survey?
<JeroenH> Survey can be found here: https://
Rachael: Each sub-group maps to WCAG 3.
<tayef> Got it! Thank you Rachael
SydneyColeman: Having trouble submitting. alastairc: people need to be a group member. Contact co-chairs if need help. Need your AC rep to assign participants to AGWG.
Draft Conformance Section https://docs.google.com/document/d/1b9g5v5Hh_Z5lFRVl3hO0Q45amG7X7KVOgVbJA_m4we8/edit?tab=t.0
alastairc: Currently 11/47 people signed up so far.
alastairc: Draft conformance. Sharing screen. Conformance sub-group will kick off in January to improve the draft being shared after the new year. Encouraging feedback on topics (Goals for a new conformance model).
… feedback collected split into two areas that the subgroup will look at. Will look into things to refine in the document, specifically if something isn't clear or other items that may need improvement for the next draft.
… definition of accessibility supported; supported sets, possibly the scoping section.
Rachael: Functional needs is another topic. Obvious default for FPC is not clear. Time permitting, would like to cover that also.
alastairc: Section of draft for normative and non-normative. Section for core requirements, supplemental requirements, (and a third).
<Rachael> accessibility supported in WCAG 2.2 https://
alastairc: Starting with 3.2.2 Accessibility-supported. Someone making a conformance claim. Need awareness for the techniques that are being used by the user agents being used. Concept of two accessibility support sets that are tested against. Web tests include using a keyboard, assistive technology, etc. WCAG 2 doesn't call out these by regions or other
scenarios (example: closed system).
<Rachael> +1 to a subgroup but after conformance subgroup wraps
GreggVan: 1) There are areas of the world where certain assistive technology is not available or not used for various reasons. A concern to consider is that web is universal. Screen readers in Japan are not the same as JAWS. Look at this consideration when testing. 2) Need to say what we mean by it; testing 300 different cases may not be realistic.
Suggest talking about 'features' in AT, rather than AT, such as reading alt text. If we are going to use this in a practical sense, we should think about a standard testing tool that could look at different AT techniques and run it against the content. This would also help new AT come into the market to test their own products against the
documented techniques. Worried that accessibility support is an impossible thing to do for us, much less for anyone else. Suggest Task Force to create a common tool to maintain and support this tool. Eliminates calling out ATs in AGWG documentation and leveling the playing field. Last callout: as AI is developed, it could be added to the tool
without requiring adaptations. Testing time would decrease with automation because the tools would solve them.
<shadi> (reminds me of attempted Accessibility Support Database from 2011 w3c/
<Zakim> hdv, you wanted to respond to sets
hdv: Excited to provide methods that work for the users and for regulators to be confident that something would work. People need to know what works. Region-specific AT testing does make sense due to various cases. Regarding features on AT, we need to test what is in the methods and knowing that the testing methods work. Lola Odelola at the ARIA working group is
working the Accessibility Compat Data project and align the work, subjects. Lots of browsers, lots of AT. Regarding AI fixing issues automatically… we used to have the Accessibility Features Community Group, and for many WCAG requirement we can to automatic fixes that aren't AI, but solveable by things like CSS. How the requirements are written are key to success.
<Zakim> alastairc, you wanted to comment on the size of task and how to make it practical
<Priti> Creating and maintaining Accessibility Supported sets is nearly impossible task
alastairc: Chair hat off. This could be an extra large task which includes software/hardware, AT, browsers, etc. Need to be practical in what's being defined because it isn't universal. Proposing 80/20% rule to keep it manageable for AGWG. WAI doesn't have capacity to take this on. Looking for a mechanism for the 'default.'
GN015: Follow up to Greg's comments - do we lay down HTML standards in the tool?
GreggVan: Start with that, but not end with that. WCAG to be done not just for Web. Encourages correct use of HTML. Makes sure that authors content follows HTML and that AT reads it. Proposing AT models and browsers to do it the same way to make the experience more successful for users.
Makoto_U: Provided insights to screen readers in Japan. Japanese version of NVDA is available now. PC-Talker (pc) has 75% marketshare. Has delayed support of newer features. Challenge in testing AT using different techniques.
<shadi> https://
shadi: Sharing his experience with past attempts. First in 2012-2014 called accessibility support database which the front-end has been removed and data is in GitHub. The large task is to look at browsers and AT combos and what is supported. Issues found, and large effort required. WCAG 2 structure and lack of clarity of some of the requirements
were another challenge. Just because it failed, doesn't mean it can't succeed. You don't need to test every single feature, and there are certain areas that are more at focus, where you don't have to fill out the entire matrix.
… done for WCAG, not for ARIA
<Zakim> alastairc, you wanted to comment on tagging methods by AT support
<hdv> and there's ARIA AT https://
alastairc: assuming we went forward with accessibility support sets, we would probably tag methods by support sets, instead of a particular AT. Technology or regional reasons to have different support sets. People, organizations or regional regulars could specify an alternative accessibility support set. Regions would set their regulations to name
accessibility support sets. WCAG to stay general in its definition
Scott: Has concerns, specifically about how it is documented.
alastairc: Normative and non-normative text to be provided.
Scott: Concerned that having a list of UAs and ATs being wrapped in red tape.
alastairc: Timestamps could be provided when WCAG 3.0 is published, and ability to update after publication.
<graham> +1 to Scott
<DuffJohnson> +1 to Scott.
<hdv> +1 Scott
<Priti> +1 to Scott
Scott: AT vendors design products to serve different users. Need to provide them the flexibility for AT vendors to test their products (which may be against how WCAG recommends). Example: AT doesn't announce option roles, which may or may not be a failure.
alastairc: Sees support on Scott's point of view, and care needs to be taken on how the text could be written to account for this issue.
GreggVan: In January, we will have a Learn and Try tool released, which is meant to be a comprehensive list of all the computer access AT and build-in access features on various platforms. Encourages feedback from this group about the tool. If you standardize wrong, you crush innovation. What about Standardizing data access and approaches and
document them for AT users, AT manufacturers. If we can say these are standard, documented and supporting ways to access the data. Having different people doing different ways creates havoc for the authors. Suggest that any new way also supports the old way, and users may not have a choice as to which tools they can use. Examples: some screen
readers have different architectures. Documenting a common way to do it may be beneficial.
shadi
… regional or government setting up accessibility support sets. Held a 2013 workshop for governments and regulators; they looked at the W3C to provide these sets. Twelve years later, we are here.
<shadi> https://
alastairc: Asked Shadi who attended the workshops?
shadi: Attendees were mostly US and European, and remote people participating from Japan and elsewhere (maybe also from China?). Had divergence in the AT world; wasn't as coherent today, and we did have countries. Need to go back and look. He provided the URL above.
graham: Should we not be looking at meeting standards and saying, you have complied with the correct way to do this thin, if the AT itself does not support a thing. That is not on an author, and I don't think it ever should be. Perhaps we flip it, here is the minimum way to implement this, and these are the supplemental bit of information. Let the
AT be the ones worrying about not supporting what we say. Having a list of supported technologies then shows a sort of bias toward the technologies, and becomes political.
<scott> +1 to graham's comments
<Heather> +1 to graham comments
<Francis_Storr> +1 to graham's comment
<Zakim> Jennie_Delisi, you wanted to share about default settings and to
Jennie_Delisi: 2 use cases for those unaware of times there were less technical individuals who only need to test the less technical areas; the world we use as part of testing has changed (operating systems, browsers, level of personalisation has changed). We have to consider their needs when writing these pieces as not everyone is trained or need to be trained for simplicity.
Jennie_Delisi: They personalise their environments, displays, and AT now have more personalisation options. Given current status of technologies, however we write them we should consider less technical users and be cognisant of their settings and environments.
<Zakim> alastairc, you wanted to comment on 'meeting standards' vs AT testing
alastairc: Talking to graham's point around meeting the standards rather than taking AT testing approach— this was the same approach that WCAG 2 took and it didn't work. Universally, as in certain regions, some techniques didn't work such as with PC Talker.
alastairc: You had to do different techniques. What we're trying to do with accessibility support series is to acknowledge the variety of techniques available.
alastairc: Some have poor support for standards like ARIA, so should we just get rid of those methods or techniques?
graham: Rather than specific techniques, more of "this is what it should expose" — take the actual end AT out of the equation and it must expose in whatever is the correct way to do it on the OS/environment you are in. In the non-technical aspect, the same can be done for non-technical things such as being able to check colour contrast, text, etc.
<scott> again +1 graham.
graham: There are non-AT-dependent ways to phrase things in this way. This is down to the AT company to improve the product and account for those who have done everything correctly and should not have to do workarounds. If instructions don't work for certain ATs, it puts the onus on the wrong place. Less move towards standards and what to expose to AT, and not worry about how AT handles it — I believe these are separate things.
<GN015> +1 to Graham
GreggVan: I wanted to echo the last comment, but you can't tell them to build standards if you don't have a test tool that you can use to test whether or not you work to the standard. If you tell me I'm supposed to build a standard, would you need to try all different types of AT?
GreggVan: By going the standards approach, you eliminate the issues of maintenace, etc. Whatever the cost to maintaining this will go to the companies—- we can guarantee it will save you in your own personnel's time. Companies will not have to live with our rules and complain about them because they're hard to test.
<Makoto_U> FYI: Accessibility Support Information for Japanese web content https://
hdv: I agree with graham's point on putting onus on toolmakers would be better. I don't know how we can make that happen as standards makers because we don't have regulatory control. It would be better if toolmakers/AT makers improve their compatibility with technologies rather than individuals checking against a list.
hdv: I am worried about maintenance, if we stop maintaining, we need a plan for avoiding that situation and will be tricky.
<Zakim> alastairc, you wanted to comment on whether to make any changes...
alastairc: Does anyone think there is a current change to make in this draft or some improvements? These would be feeding into the subgroups starting January.
<Jennie_Delisi> Proposed changed under 3.2.2.1 "This is the set of UA, AT, and settings that AGWG will test against..."
<Jon_Avila> Standards like the CSS spec can evolve faster than assistive technology has causing barriers for months or years to access.
alastairc: To graham's comments, I would like to agree going with standards-first approach but the first, but how does a regulator know that meeting the requirements meets the end-user need? If you're in a particular region, if you've got AT that does not meet standards, there need to be clear markings of such so that you know these methods don't, and some do.
alastairc: Nothing stops us from having multiple methods for different requirements. Some methods with accessibility support sets is a specific ARIA way of meeting standards, but it may not be supported by certain technologies. Think of it as tagging methods so that you know which ones would work in general at the core.
Ben_Tillyer: Starting on the database of sets is going to lead to a lot of pain, it's difficult if you have more than one person working on one of the tests, it's going to be hard to make sure they're testing environments identically for the purpose of the test.
<bbailey> +1 to Jon's concern in IRC
<alastairc> The previous discussion on the default set: https://
<Jennie_Delisi> +1 to Ben in terms of difficulty given impact of environment differences
Ben_Tillyer: You would need the entire set of technologies from hardware, software, browser, OS, AT, all included in one package to say that it would work for a user. I wonder if we could have a template or some sort to prepare to give to AT vendors and browser manufacturers that ask them from a technical standpoint whether something is supported. Like graham touched on, if it is exposed to the accessibility API in the browser. The responses
from these templates could get information on what would theoretically work for users without doing a lot of testing.
<Jon_Avila> I think we are talking about 2 different things here - bugs/tester misunerstanding vs. actual AT support for something.
<ShawnT> +1 to Ben, devs assuming that's how the person uses the AT
Ben_Tillyer: A lot of people in QA roles I've met report things that aren't labeled as exposed to AT would be reported as defects, but there are various bits of information that need to be captured that give people confidence that they meet accessibility support.
<GreggVan> to not use new methods for data access when the old way works just as well. We would/should however not restrict new access or presentation method innovation.
<scott> to add on to what ben is saying, there can absolutely be bugs introduced at any time into UAs, ATs, or due to author/customer created content. at any point in time a 'supported' UA could have a regression that could make the list of supported UAs seem suspect at that moment in time
Heather: Appreciate those who talk about different stakeholders and new documentation for them and talking about innovation at the AT level to make their own decisions on how the AT is used based on their user base. If any changes need to be made would be minor.
<Zakim> graham, you wanted to say we use this list as a "minimum supported" method and an ideal output. Also move the guidance to "here is how to check this in the accessibility tree".
graham: How do we address this? You have to develop a guidance, technical documentation that say what it should include depending on platform, and you have a test as guidance for the ways you can do it and the tools to use, things to look for, and we move away from physical ways of testing with a screen reader other than making sure our assumptions are correct.
graham: I envisage getting to the point where you can pick your technology of choice to your AT, test with it, and if you have issues, you can fall back to doing something that we have prescribed that if you meet things things, you're okay, and you've made sure it is correct, and this is an AT problem.
<Zakim> GreggVan, you wanted to say and to say " we are looking at changing Accessibility support from "work with AT and Accessibility fearures of UAs, to "workng with a set of standard ways that AT and accessibility features use to access and present information" snd then create a tool that contains them. This would remove both the "which AT" (and our having to choose favorites) and make it much easier to test. It might also over time cause new AT and accessibility features
graham: How we update these documents, where we can prescribe techniques, is what we use for the accessibility support sets for because we can then have the lowest possible standards that would work.
GreggVan: Looking at changing accessibility support from work with AT, accessibility features, to work with a set of standard ways that AT accessibility features access and present information, and create a tool that contains those techniques to remove which AT you have to test with.
<Zakim> alastairc, you wanted to comment on complexity - we would be writing a method and establishing if the AT in the default set "supports", not that it's the same.
GreggVan: Instead of listing any list, we should say we are looking at whether or not we should be tagging inside the document or outside, with functional limitations. Any list we have is broken and we could spend weeks trying to come up with a functional scheme. We should take out the list that is in there currently, but ask for suggestions and look at other ones
alastairc: Need to clear up assumptions… this is at the method level, what graham was talking about looking for web techniques— when we are writing a method to meet a requirement, e.g. if something like a button has a name or heading levels; there are known ways to meet a requirement, but we are not providing all the possible ways. What is our minimum bar for saying for us providing it and saying it works for people.
alastairc: graham's suggestion about telling ATs should do this, it leaves a hole— you don't know if you put your product meets WCAG and everyone using a particular AT is out of luck for a particular set of methods that you've provided.
alastairc: There has to be some practicality without having to have a database of things of what supports what. The proposal is we take it at the method level, we test against the current set of accessibility support set and are happy that it works with that. We need to know which ones are supported and that's what this proposal is about.
Jon_Avila: Building on what alastairc was saying, we need a layered approach and the problem on just relying on standards is, if no screen reader or AT doesn't support them, people who rely on screen readers won't be able to use those particular features. If we have methods documented such as techniques — and we say that you are not following them, you have more proof to say that I am following a standard and it works with this AT.
Jon_Avila: You can have a higher bar and use other methods, but you need to demonstrate that it works. There might be a third layer that we've tested/conforming against these set of technologies that might be needed to support different technologies in different regions and so on.
<Zakim> GreggVan, you wanted to comment on "sufficient" as a way to handle at mehtods level
GreggVan: We're taking our rules and testing only against a certain set of AT, if someone buys a different AT, it may not work and we have not tested it. We have now said that this is the rule and it worked with our favourite AT, so you need to buy that AT or you don't know if any other AT will work or not
alastairc, can you please put the link to that document here? (I might have missed it earlier)
GreggVan: We're not really testing these things with all those ATs, we ask people if they know if these do/don't work.
<alastairc> https://
GreggVan: We shouldn't be basing our techniques on mainstream standards, but against a set of standard accessibility access and presentation techniques so that those used and supported by AT would be broadly supported. Now do we only include things in there that are supported by the weakest AT?
GreggVan: If we put that as not a rule but as a sufficient technique, if you work with our tool that tests all of the standard accessibility access/presentation techniques, it will be considered sufficient. Just saying "if" you did it with this, it would be sufficient.
<Zakim> Jennie_Delisi, you wanted to discuss AT alone
Jennie_Delisi: Going back to GreggVan's earlier comment about features that provide access— want to clarify under 3.2.2.1 heading saying this is the set of UA and AT, is that where we might run into issues for users that are using those features that now become more ubiquitous through OSes/browser settings/etc that will provide access, or do we have to specifically call out those features there?
graham: Jon_Avila made an excellent point, I'm on the same page but we've made the argument of the CSS standards and we now have evergreen browsers. If there are things that we have in standards that AT providers have not put in, we get to the point where the pressure becomes you need to include the things that are standards compliant and we end up in a better place. I know it's a problem short-term, eventually we'll catch on where new AT may
enter the market and approach things differently. Once they meet the standards, they have a viable product that can be better or can compete well with others.
<Zakim> alastairc, you wanted to say we can (and should) start with the standards, but we need a filter / mechanism to say what actually works.
alastairc: Not sure we're disagreeing a lot, this is from the POV of picking up where WCAG 2 was and the changes/differences more than what's the same, but we should start with those standardised and standard, but this is a filter mechanism that actually works. If we can get to the level of having a method that is based on a standardised way of doing things, we should do that but how do developers know that it will work?
alastairc: To Jennie_Delisi's point to user agents in AT, we're including user agents, so it's not just AT and we're writing methods around text, spacing, sizing, contrast changes, dark mode, etc. we should be including that as part of this.
alastairc: If we write it, they will come — the browsers have gotten good at standardising on things like CSS, but that has not historically worked in the accessibility sphere. The user agent guidelines were transformed into non-normative notes because many did not agree on us being able to specifying that.
alastairc: We're not allowed to be writing normative requirements for user agents. I agree we should be starting from a standards first point of view, but this is an explicit thing on how you should do something, we know it works, and with this default set, you can make a claim for a different set of user agents.
<kirkwood> odd title
alastairc: Wanted to pick up on the functional limitations — they're not actually requirements but limitations or non-working in some ways. We can take GreggVan's point to turn it into a question.
<bbailey> s|s/roles in WCAG2ICT/roles in WCAG2-Issues (aka, backlog)/||
LoriO: At the list of functional limitations, do we need an actual list? This is not a list of every single thing that could cause a person to have a functional limitation. There are many variations of everything that would it not be better if we had a general type of list and not a "what we think" list so they can come back and say that you missed a whole group of users. Is it wise to have a specific list? Or should it be more general, perhaps
statement?
alastairc: Should we go over the purpose of what was included?
LoriO: How do we know what everything actually is because that means we have to list everything.
Rachael: The purpose of this list is tied to the particular conformance proposal that within functional needs is a way to meet our goal of balancing or providing more equity that people would have to meet a percentage.
<kirkwood> functional needs is better
<alastairc> kirkwood - but the titles of things in that are not "needs"
Rachael: Most of the legislation have functional performance criteria that are not sufficient in two ways— there are things that are missing that we know we have requirements, and they are dramatically different within each one of those. We need to find the sweet spot in the middle— we need to get it in front of the public. This is not a list of disabilities but a list of needs that are limitations that are tied to those.
<Zakim> Rachael, you wanted to react to LoriO
<bbailey> just FYI background, here's 508 fpc mapping for wcag 2.0: https://
<Jon_Avila> I think we need to split limited vision and limited color vision out because we need a cleaner mapping for needs.
GreggVan: Please clarify as to why it was needed in the normative content? Which functional limitation each one relates to does not seem to be in any way required in order to know what I need to do. It's confusing me because it doesn't tell me that I need to do this except it has to solve that problem for those people. You missed a whole bunch of people not listed here, and lost a whole list of different cognitive. What is the purpose of having
a big taxonomy and tagging things as informative?
<bbailey> as Rachael notes, the "With Limited Language, Cognitive, and Learning Abilities" is a very broad bucket
<Jon_Avila> It's needed so we can make sure we have sufficient supplementary coverage
<Zakim> GreggVan, you wanted to say "what is the purpose of this? "
Rachael: The model we have right now going out in this draft before the conformance subgroup adjusts it, does say that we are going to subdivide by functional needs which means each item would be tagged by the functional needs supported b y it. This particular requirements support in a meaningful way, these particular functional needs, and when someone looks at the conformance report and checks it against the supplemental requirements we have
provided support for we should include it in this draft and get more feedback on whether this is a good/bad idea.
<kirkwood> actually given thes conversation and past standards i’ve been involved with may just be “functional needs and limitations” could work
<GN015> I even think gaving everything for a single group is a greater support for end users than having a bit of support for each group.
Rachael: "Should we do this" from a conformance standpoint, and "is this the right list" — sounds like a no, so do we go smaller and glom things together? Should we put all vision together? Do we break it out across a larger list? This is a conversation we wanted to talk about today. Going back to conformance, based on all the conversation the past few months, where we landed was that the things that must be done in the core set, and things
that increase improve the experience in the supplemental set, and in some ways it ties to the problem/errors to use something. The more supplemental you fix, the reduced burden you have. Can you solve some portion of these supplemental challenges in addition to the things you must do. One is the model, and the other is what is the right list here.
<kirkwood> Functional needs come out of addressing the functional limitations, no?
<alastairc> kirkwood - yes, but the phrasing is hard, the functional need would vary a lot, by requirement almost.
<kirkwood> limited visual processing? limited visual attention? for example?
GreggVan: I agree with the things that you must do and the thing you can do beyond that to make it better, but I don't agree that you say the requirement is that you must do all the things that are really important, and then even if they are not essential, we're going to require as law that these are based on discrimination laws. You need to do a bunch of extra things that we're not gong to require you to do and that makes no sense to me. Every
time you have a pick from list, you move out from the "this is required, not discriminate" you move into "you get to pick".
<Detlev4> Logging in for the fourth time today. :(
<alastairc> kirkwood - "limited visual processing" isn't a need, that's what you have, it's a limitation.
<Detlev4> agree with Gregg the the logic of "some of the supplemental" is flawed
<kirkwood> true functional limatiations
<alastairc> Sorry, you being "someone"
GreggVan: The things that are just usability for some people are roadblocks for other people.
<Zakim> GreggVan, you wanted to say a short comment
Rachael: We need to move to deeper conformance conversation but there is tension between needing to take steps towards needing to be perfect. The differentiation between the core and supplemental, the level of effort, the concept of equity and level of effort. If you have one error/spelling error in a document, it's not a big deal. When the document has a ton of errors, it's a blocker.
Rachael: In some ways that supplemental is trying to approach that problem set where if you have all the supplemental and you're not doing any of them, you have a significantly bigger barrier than if you work off some of them. We want flexibility as a compromise space to make the experience better.
<kirkwood> Yes, the limited visual processing. or “limit ed visual attention” Maybe that needs are a simpler interface
GreggVan: This idea of cumulative cognitive load — if you only have to do one of them, you can fight your way through it, but if you have them stacked on top of each other, it overwhelms.
GreggVan: All these functional limitations assume a particular conformance model and we should figure out what the conformance model is.
<kirkwood> this is a good list to get us thinking btw
GreggVan: The functional limitations are only put in to even out that we're doing this scoring technique.
GreggVan: Talked majority of our time talking about things that were not included because they couldn't, and I don't want us to spend so much time on having to do this because we've spent all this time talking about it.
<kirkwood> very very good list
<Detlev4> can you link the doc again Alastait
alastairc: Our focus is what is going to get the best feedback?
<kirkwood> limited porcessing should be added