Julie: Clear Language has been on hold since TPAC. Waiting for feedback and clarity on what test types will be for WCAG 3.
ShawnT: The WCAG2ICT group has a simplified scribe instructions: https://
Rain: trying to figure out what adaptive testing will look like. Adaptive testing means when there are different conditions there will be different results. This is an area COGA has a lot of potential.
W3C assertions survey results: https://
Lisa: Need to look at survey results for assertions testing and see if COGA agrees with them.
Sneak peak of draft assertions doc from Rachael--not final: https://
Julie: Assertions survey: https://
Julie: Rachael's draft assertions doc: https://
Julie: Concerns with definition of assertion in initial document, as well as how much of Clear Language work would fall under an assertion.
Julie: unclear what "documented statement" means in assertion definition
Rain: Likely refers to formal statement - something findable or public
Julie: concerned with the language that assertions "cannot prove that any desired result occurred"
Lisa: suggest 3 types of assertions: 1) saying they are doing it, but cannot prove it in any way (for example, "this sentence is easy to read for me"); 2) things that are completely provable and the proof can be provided upon request (for example, inclusion of many people with disabilities in user testing); 3) provable but not via WCAG binary testing processes (for example, general common words vs. content-specific common words
Julie: at TPAC, clear language had a draft test that is similar to what Lisa is suggesting in #3.
Julie: Concerned with current language because it appears that you can assert anything and it is not rigorous. COGA should be involved in how assertions are defined because much of clear language will mostly fall under assertions.
Lisa: very concerned that assertions will only be at silver and gold level but not at bronze level.
Julie: if assertions are only at the higher compliance than people are less likely to adopt them.
Julie: some protocols and processes take a long time to adopt - are you making an assertion when you are starting that process? Or can you only make the assertion once the process is complete?
Lisa: concerning that you can have a process in place but there can be exemptions (e.g., it takes too long to implement)
Julie: Can you make an assertion that says you're going to prioritize some areas (high-traffic pages) but don't have a plan for full implementation?
Lisa: concerning that you may be able to make an assertion that you have a process without having completed the work toward implementation?
Julie: debate to have - making an assertion when you're in the process of implementing with clear supporting documentation regarding the timeline or waiting for full implementation to make assertion
Jan: the definition of an assertion is too broad. COGA should provide feedback that there is a need for a more robust framework re: what components are necessary to qualify as an assertion.
Julie: In current assertions doc, suggests that procedure must be fully completed before an assertion can be made. Can there be nuance around what has been done and timeline for full completion?
Lisa: Assertion can be made for a specific scope
Julie: Not clear when assertions should be used.
Rain: The plan is that will be included in the guidelines themselves.
Julie: Will clear language be just one assertion in WCAG3? Or can some aspects be broken out into binary testing?
Rain: That is for us to propose
Rain: for example, you can make a claim that there is a team of people with intellectual disabilities review your language for understandability, which would be an assertion vs. in English, avoid double negatives, which is testable
Rain: we as a subgroup need to say that some aspects of clear language are testable and documentable and others are less provable.
Rain: if a company has a confidential style guide they follow, for example, they are making an assertion. But the publicly available content may not actually confrom with testable guidelines, so would not conform by those standards.
Rain: organizations should be approaching this from both sides.
Julie: may be asserting something that is also testable in another way (e.g. double negatives to express a positive)
Rain: there is merit in rewarding content producers for being proactive (e.g. developing a style guide) even if day-to-day employees may make mistakes that make website not fully compliant.
Rain: but it is up to the subgroup to propose those differences
<julierawe> Lisa, how do you spell "erl"? or what sounds like "erl"?
<ShawnT> EARL? https://
Lisa: there is a specification called EARL that likely addressed many of these assertions that we should look at.
Julie: will reach out to Rachael to ask when she would like this feedback before creating a google doc of feedback
Julie: Will send feedback to full COGA team