Meeting minutes
<gb> CLOSED Pull Request 2 fixing typo (by dret)
<gb> CLOSED Issue 3 Avoid human text in attributes (by michael-n-cooper) [i18n-tracker] [action required]
Lionel_Wolberger: We are meeting next week. Sharon chairing, her last meeting.
Lionel_Wolberger: We won't meet on the 26th of December.
Lionel_Wolberger: We won't meet on the 2nd of January.
RESOLUTION: We will meet on the 19th of December, and the 9th of January, with holiday in-between.
Administratrivia
WKU for Accessibility Statement
I think we should focus on what we want to discuss of the three areas (explainers).
https://
matatk: We are using the discussion feature of github to discuss well known uri (WKU) issues
… Names are important, not sure if calling this "WKU" is the best label
… as we might end up talking about other related topics like 'rel'
… proposing 'Information Architecture'
janina: Yes, vocabulary is important
… well-taken, that we are using multiple mechanisms to reach the results we are chartered for, and have already in our explainer
+1 to broader vocabulary
janina: we will likely be using an adapt- (adapt dash)
Naming this workstream
Abhinav: Will we want to eventually register this with IETF?
janina: Register what is appropriate to register. Where we use WKU we would register that with the IANA
Abhinav: The IANA requires the endpoint to be declared
matatk: We could say that it would redirect, as we just want to allocate the WKU
matatk: The 'rel' attributes would relate to microformats or the HTML spec itself
… we do have to agree on the keywords that we are registering,
… likely be the destination values that we got from COGA
%s/IANA/IANA
Lionel_Wolberger: We've agreed that we will register the URLs with IANA. We have not yet agreed on what we'll register,
matatk: Since that registration is public, we would need to go through some validation process internally (with TAG? or others?) before we register
Process, timeline
matatk: We (Adapt TF) are discussing the 'WKU' Explainer on GitHub (discussions link above). We should keep going there until we have something to bring back to the group.
matatk: The TF should clarify process and timeline regarding human readable vs machine readable accessibility statement
… the presumption is that we will have both; the machine readable is more complex, requires a much longer process
matatk: We discussed last week that we'd look at the schema.org schema we found, and then take that to WAICC for futher input, once we've reviewed it to see if it needs additions/changes.
+1
Janina: We (APA) definitely would like to do this, but needs to be as part of WAI.
Lionel_Wolberger: We have to be tactical and practical, let's move this off our table for now, but it fits so well into the passion we had around WKU.
… I was excited because all sites have accessibility statements, so thought we could get a standard pointer to it, without tackling machine readability.
Abhinav: There's another discussion topic, about translation that we need to add.
… Also about accessibility meta and reporting - I made some comments there.
… If human-readable, do we want to do a redirect, or have everything on a single page?
… If single page, then it can't be a redirect.
matatk: The explainer should make this clear, that the end-user can control which format they would accept
janina: Whether github discussion is sufficiently accessible remains to be determined
matatk: We turned to RQTF on that
… they said if the discussion is not accessible enough, then we can turn them into issues
<gb> CLOSED Pull Request 2 fixing typo (by dret)
<gb> CLOSED Issue 3 Avoid human text in attributes (by michael-n-cooper) [i18n-tracker] [action required]
WKU vs. Destination
Issue 240
russell: (Summarized the 'Using Bliss Unicode Instead of BCI-IDs' that he sent to the list)
matatk: +1
matatk: This looks sensible, as it retains the outlines of what we worked on, such as the registry
Lionel_Wolberger: I'll take matatk's excitement as we don't have to redo all that we've done. I'm not sure that the puzzle is cracked just yet.
… Where I'm not sure: I think russell did all the heavy lifting and cognitive work to establish in a dispositive way that unique IDs on the Blissymbolics table could be formed out of unicode.
… The uniqueness and non-ambiguity would remain, as would functionality of look-up.
… And this would still achieve the aims of the spec.
… Does that mean all aspects of the code numbers are resolved?
… If I wish a simple semantics to indicate 'I want an image here, in the end-user's image vocabulary', what is the best way of indicating that?
… If I do it with unicode, do I use an emoji, or the words, or Bliss symbol?
… This is not semantic.
… Semantic would be unambiguous code to say 'happiness' e.g.
Lionel_Wolberger: I suspect emoji would have a rich enough vocabulary.
russell: I don't think emojis will do the trick, There are a lot of them but they're limited.
… Using a unicode encoding, we could use any language e.g. just the string 'happiness'
… But the problem is there are so many words that have multiple meanings.
… I understood Bliss was chosen because it was a set of concepts derived from the AAC world, and would be well known, and map to the core vocab of the other AAC systems.
… Emojis wouldn't be good for this.
… Maybe for emotions they'd work, but not in broader vocab.
Lionel_Wolberger: Let's lead the agenda with this next time.
Lionel_Wolberger: We've determined that for the lookup function, BCI IDs and unicode are interchangeable. I'm concerned we'll get lost in unicode.
Lionel_Wolberger: We have determined that for the conumption use case, Bliss Symbolics IDs and unicdode are both suited to purpose
… the open question is whether for the authoring use case, they are both suited to purpose
janina: And I think the people who raised the thread are not thinking about authoring