<jamesn> we are in #pwg
<jamesn> https://global.gotomeeting.com/join/994278485
<jamesn> we are in #pwg
<ZoeBijl> we are in #pwg
<ZoeBijl> scribe: ZoeBijl
https://github.com/w3c/aria/issues/1044
<Jemma> https://github.com/w3c/aria/issues/1044
JD: James Craig how strong do you feel about linearised?
JC: *scribe fell behind*
Who is the primary client fo this CSS spec
It felt like this was a similar thing
In medium/long form articles
scribe: or books
The pullquotes which were he primary case
You might want to navigate to them
But read them in the linearised version
This is kinda like a CSS media type
If you tell your SR to “read all” you don’t want it to announce repeated content
JD: So repeated content are things that you’d want to be read in certain context
JC: yes
Like with VO if you do a two finger swipe down it’ll read the entire page
You might no want tthe repeated content to be read
My issue with the current proposal is that it might be too narrow a usecase
Perhaps we can apply this a broader use case
*James Nurthen makes a joke about aria-sometimes*
JD: So you’re saying… aria-linearised set to default?
The content author sets when the content is read.
But should it be the SR that says “hey this is repeated and my user said they don’t want that”
ZB: Would something like an aside be another example of “not entirely relevant content”
*group is unsure*
JN: Redundant links
Anything that’s not repeated you want to read all the time right?
*group agrees*
Can we come up with anything that’s not repeated content
MK: I like the word redundant bettter
JD: You do? I think I do too.
JC: We should look at vocabulary
I think repeated content is a lot clearer and easier to understand than redundant
ZB: I agree, I think repeated is easier and more appropriate than redundant
Maybe we can make redundant a synonym ;)
MK: I’m not entirely sold on the use case period
If we’re trying to craft the end user experience
the screen reader experience
in ways that assume the SR user’s intent
you need to somehow, the screen reader, needs to somehow communicate their intent
JD: SR would have to implement an option for this
MK: JC you said something about the two finger swipe down
JC: if we know the authors inttent
and it’s declaritive
MK: Having it be a SR option instead of a content option
Would make it a per user thing
I don’t think SRs need more options
ZB: could this be incorporated into a SR’s verbosity settings?
JC: We already have something for repeated labels
MK: That could be
But the difference between reading a text book
<scribe> continues reading
versus not wanting to skip them
ZB: do you find it annoying to get repeated content read to you in articles
MK: That can be a bit confusing
<Jemma> +q
Just trying to figure out who is responsible for that
MK: it feels like something that has good intent and could be useful
But before you put it in a spec it ought to be tested with real people in real situations
What would implementations look like?
JN: Isn’t that the way we work?
Freedom Scientific already said they’re interested in it
JC: Just want to emphasise that I don’t like redundant
JD: Can you comment on the issue?
JK: we already have landmark roles
if we look at the landmark concept
you can skip the navigation
JD: using pull quote as an
example
... you can mentally ignore it
Because it’s styled differenly
So visually it’s easier to ignore it
That’s a lot harder if you use a SR
<jcraig> Issue?
https://github.com/w3c/aria/issues/1044
*something about repeated headers*
Well he and others are debating that
JN: That’s not our debate
MK: It’s kinda interesting
Like 90% of the headers is repeated
But the page numbers aren’t
But I often like to hear page numbers when I’m reading a book
It makes you aware of the transitions
JD: dPub has a role for that
Perhaps we can use that
But for truly repeated content we could use aria-repeatedcontent
MK: I’m not too annoyed by repeated content
JN: Yeah but if you get a long pull quote it might be different
MK: I agree
JK: Are you saying that a pull quote can’t be a separate issue?
JD: Most users probably don’t want to be interrupted by all this content
<jcraig> Commented in the issue: After the F2F discussion, I withdraw the suggestion for the broader approach. I think “repeated content” or something similar is easier for authors to understand than the concept of linearized content for screen reader reading modes.
Unless you’re proofreading or something like that.
MK: It could be a nice feature to have
<chrishall> The minutes from yesterday don't seem to have set <tink> as scribe for "HTML Accessibility Issues" https://www.w3.org/2019/09/15-aria-minutes.html
<chrishall> Yesterday this was resolved by someone inserting a scribe historically via `i/Table Ontology/scribe: ZoeBijl`
<inserted> scribe: tink
<chrishall> So something like `i/HTML Accessibility Issues/scribe: tink/`should resolve that.
<chrishall> heh
<chrishall> ty
<jcraig> https://github.com/w3c/csswg-drafts/issues/3708
<jamesn> we are now in #css
https://bocoup.github.io/presentation-aria-and-webdriver/#/
<spectranaut> https://bocoup.github.io/presentation-aria-and-webdriver/#/
<scribe> scribe: ZoeBijl
<Boaz> link to slides: https://bocoup.github.io/presentation-aria-and-webdriver/#/
Note: this meeting will not be minuted as the script for the talk is in the speaker notes. Potential discussion after the presentation will be minuted.
Example of pushButton documentation: https://bocoup.github.io/aria-practices/aria-practices.html#automation-pushbutton
*JC pointed out that close attention should be paid to how the role of an element is determined*
Related to the “inferring the role” part of the proposed documentation linked to earlier ⤴️
*start of discussion/feedback*
Val: again there are multiple ways to check something like a button’s label
Do you think the guidelines are stable enough to use it for this?
Is the time now to do this?
So we’re testing ideas that are in the APG
Those are the topics and questions for now
SP: This is webdriver extensions
In that sense it makes sense to document them in the webdriver spec
AutomatedTester: the webdriver spec tries to give us primitives to allow people to automate
with WD we think we have three audiences
web qa person
spec authpors
and people that want to write automation for something
Like a webcrawler
We try to cater to these three audiences
and we try to make the primitives as low as possib;le
I’m not against this being in the WD spec
But perhaps it’s a new primitive
It’s not like a core…
Not how e historically thought about this
It’s not a subset of people
that’s why I wasn’t sure if it fits in the WD spec
That’s where my initial gut feel came from
average user, it’s kind of like, fitting those three groups of people
The spectrum is incredible broad
How does that fit in
With push button as an example
No one has come to us to ask “how do I push a button”
ZB: I think it would be good to automate this, take away people having to think about accessibility
Even if no one asked for that
AutomatedTester: absolutely
And then you would go and try and do a click or keyboard interaction
And at that point it uses the accessibility tree rather unlike DOM commands
So what Val and Simon were saying
You get these stale ????
If you did find it
and you try to interact with it
you throw an error saying “hey this isn’t in the a11y tree”
JJ: I was thinking in the case of the examples
the dev would have alrteady have given the role to the element
I think it would be more interesting to tell them ??
Would rather have it say click this role via the accessibility tree
Val: I think that’s the intention
JC: Pitched this idea years ago
Probably in some other repo
Some of the primitives that this could pile onto is element.computedRole
Not necessarily go through the script but ask the engine
You can get the role and label from there
You can find elements by computed roles
AutomatedTester: can we get this via JavaScript?
JC: No
<aboxhall_> element.computedRole is experimental and buggy
It’s going through the DOM tree, but that doesn’t necesarily mean that the browsers are doing the right thing, you can’t check that through the DOM.
JN: I believe you can get it in puppeteer now
JC: Getting access to the entire accessibility tree is going to take a long time
Getting access in webdriver would be trivial tho
SP: Why wouldn’t we give access to all developers
JC: That’s a good question, right now there’s a significant performance hit
SP: Is it heavy to request the role of an element?
JC: Not necessarily but there are complications
ZB: Would it be heavy to get all elements of a certain role?
JC: Yes. I suggested a :role selector for CSS years ago. But when we tried to implement it with the CSS WG we found that it was too heavy.
Select by label (similar to what’s on slide #8) is something we use a lot to find things
This works through the accessibility tree
So I hink this is a great idea
I think this should be closer to the APG (?)
AutomatedTester: whereever it lives doesn’t stop it from being implemented
ZB: As long as it’s not he APG, because that’s a note not a spec
AutomatedTester: webdriver puts lots of effort into extensibility into its spec
I think it fits better in WebDriver
Boaz: I think the idea here is to change web developer's mindsets
I don’t think this needs to be in the WD spec
AutomatedTester: the other thing I tried to advance is
this is very input driven testing
<jamesn> ?
which is one of the easier sides of testing accessibility
<Boaz> boaz: I think the idea here is to change web developer's mindsets
https://github.com/w3c/aria/issues/1001
<joanie> https://github.com/w3c/aria/issues/1001#issuecomment-521076833
<Jemma_> https://github.com/w3c/aria/issues/1009
<spectranaut> scribe: spectranaut
<Matt_King> From the spec:
<Matt_King> "In some user agents, multiple reference relationships for descriptive information are not supported by the accessibility API. In such cases, if both aria-describedby
<Matt_King> and aria-details are provided on an element, aria-details takes precedence."
<Jemma_> https://github.com/w3c/aria/issues/1009
mk: (describes jongunds issue) the way we spec'd aria-details, it is not meant to describe an accessible description
the challenge is that we don't know what an accessible description is, and what the difference of intent is between aria-details
the content in aria-details should be navigatable to, but accessible description does not have to exist in the dom because it could be a hidden element
the main thing we would like to accomplish is: what is the content referenced by aria-details in particular? what is the AT expectations?
if you use both, you maybe overwritting the accessible description?
so are the details the description?
cl: we looking to use aria-details int he publisher context for enhanced image descriptions
say we have an image that is complex, like a table (heaven forbid) we would like to use aria-details to put a table in aria-details
or if we had an image of a math equation
can we use aria-details in this way?
when a screen reader hits an element with aria-details, it says, "has details"
we would like it to be a linkable, clickable, navigatable section
have a mechanism to the go back where they were in reading
mk: question about images. is there a reason the image wouldn't be in a figure and all of that details content would be in a fig-caption, directly associate with the image?
cl: maybe a publisher wants all of those description sin an appendix, instead of encapsulated in a fig caption with the image
mh: I share charles's interest. We generate a lot of content with complex images.
we need to provide a link to image and structure description
without aria-details, we could use a figure with text descriptio. structure info about a image and flatten it into aria-describeby is bad
I'm not thrilled with aria-details. does the screen reader need to tell you how to get to the structure content. what if that content has another link.
jn: one good thing about aria-details is that we are about to get more implementaiton sof it because of aria annotations work
hopefully screen readers will add a way to navigate to the annotation
<Avneesh> https://github.com/daisy/epub-accessibility-tests/tree/master/content/epub30-test-0340/
av epub use cases link link above
aria-details and aria-describeby is huge. aria-describeby truncates tables and does not provide good descriptions
people do not want to put descriptions by image by at the end of the page
aria-details is not announced by screen reader, but we need a way to move between the image to where the description is and back again
jc: annotations. aria-details reminds us of longdesc. but there are benefits -- same page.
<Zakim> joanie, you wanted to state we need to do something about the mappings.
BUT aria-details actually has use cases unlike longdesc
<joanie> https://w3c.github.io/core-aam/#details-id-105
jd: if there are details and describe-by is due to UIA -- if they have one description.
if microsoft can add something to their api to differentiate between aria-details and aria-describeby
what happens if both appear and we can only expose one of them?
UIA is microsoft's user interface automation
mk: support for aria-details. no one is suggesting to get rid of it. Microsoft wasn't read to support it but it went into the spec anyway. if we can get rid of the conflict that only exist in UIA then we could make aria-details fully functional on all platforms
if in a year from now we have aria-details support. from an authoring perspective, it is not the accessible description.
<joanie> Identifies the element that provides a detailed, extended description for the object. See related aria-describedby.
<joanie> The aria-details attribute references a single element that provides more detailed information than would normally be provided by aria-describedby.
mk: "accessible name and description calculation" -- aria-details has nothing to do with that
jd: confirms that is in the spec
<joanie> Unlike elements referenced by aria-describedby, the element referenced by aria-details is not used in either the Accessible Name Computation or the Accessible Description Computation as defined in the Accessible Name and Description specification [ACCNAME-1.1].
jc: annotations are not descriptions
mk: we need to find another way to communicate this in the spec not using description
what will the authoring practice say? if annotations go forward, we can include information about that
<Zakim> joanie, you wanted to ask about the "alternatively... link to web page" bit
<joanie> Alternatively, aria-details may refer to a link to a web page having the extended description, as shown in the following example.
jd: something else the spec says that we should get rid of (above)
unofficial decision: get rid of reference to "Extended description"
av: some people want to put accessible restrictions at the end of the book
they say the authors have control of content on the pages
different webpage
each chapter is an html page
last page has restrictions
av: we want aria-details to be able to link to a different webpage
aria-details links to a link that will link to a different web page
mk: we will have aria-details that links to a link. the language of the spec (above) implies the user should be able to bypass that directly -- if aria-detail points to an anchor, then the use will not navigate to the location of the anchor tag but instead to the target
is there implied UA functionality?
aria-details can point to ANY structure content, like a thousand links instead of one link
does that line imply it can skip the user to another place without rendering/announcing the link
mh: trying to minimize navigation steps is what we want. description is part of image element, it's right there, they don't have to navigate
it's not a good user experience to jump around to what should be read in context
by: I'm using aria-details
is the question: is the content of the reference just a url?
if the fragment pointed to was an anchor without any text, might as well follow the href
jd: I'm worried about the accessibility API to move back .
by: I know within publishing in general the web annotation spec could serve a similar purpose, but it takes another page and merges it together
we should move it off to the publisher group
references in aria-details can point to things that are not in tree but could be added later...? but if there is a use case to keep them separate, there must be a way to combine them.
av: authors really want to the book to look like the printed book. And that is why they want to put the description at the end
some authors want in the same html files and some want it in different ones
mk: I want to echo what ben was
saying and I think we need to strike the language about the
links and the publishers that need to put the details content
in another place out of the way then there are multiple other
technical solutions and some of them could use aria-details and
some couldn't -- aria-details needs to refer to directly to
content visible int he page that can be moved to.
... we should entertain a resolution to strike the language
about going to links
jd: I'm in favor
by: there is being discussed an include tag. go get a whole webpage and make that a description of the thing you are inside of. the include tag could provide that.
I want to bring in a whole iframe but like a description
<ZoeBijl> https://github.com/w3c/aria/issues/748
jn: read issue
<ZoeBijl> Live code example: https://s.codepen.io/Moiety/debug/3c14a0599ab1a6a6c491f7ebf4119f1d
<jamesn> https://github.com/w3c/dpub-aria/issues/15
the issue from this morning is related: dpub aria
(reads new issue dpub-aria #15)
s/#14/#15/
section number: 525 in 1.1
<Jemma_> https://www.w3.org/TR/wai-aria-1.1/#mustContain
zb: in issue 748, what is the problem with the code example?
jn: the problem is that it is defined as: owned is any descendant. In reality it doesn't work. If we need to count the number of list items in the list, it would be wrong. a list of one, then a list of one
jd: also the accessiblity tree is wonky. webkit removes useless divs. others don't, firefox and chrome have issues
jn: what do we want to do about this?
jd: I think we correct the spec and say it needs to be a direct descendant
we should change the definition of owned to be a direct descendant or direct child or anything pointed to by aria-owns
<ZoeBijl> https://html.spec.whatwg.org/multipage/grouping-content.html#the-ul-element
mk: we are forcing people to put aria-owns if there is an intermediate div
zb: reads link. if an li is a role of "item" then the code in the issue is correct
jn: you are reading the wrong section
that is the ul element -- it is flow content ... ???
zb: nevermind
<jamesn> https://github.com/w3c/aria/issues/748#issuecomment-473594928
jn: my proposal is in comment linked above
avoids problem of adding role=presentation on every random div
everyone: makes arounds of agreement with suggestion in comment
jd: I agree with principle of what you are describing but there needs to be more description. inbetween elements must have role none or generic or any other property that would force its inclusion in the accessibility tree
mk: they also can't be focusable or have text
jd: user agents need to do some tree pruning
jn: they don't have to tree prune but it is the easiest way
jd: if we put this change in the spec but ua don't do anything then it's usefully change
this doesn't work in ua and at -- so changing spec language is not enough
we can't normatively "must" the ua prune the tree
jn: I have one more question in the comment
should we also allow descendant elements of the aria-owns also be ignored in this way
<jamesn> Should we also allow you to reference a DIV with aria-owns rather than referencing the individual LI elements..... This would be really handy for tables split into scrollable regions.
jn: an extension spec. in dpub they are subclassing an aria-list expecting to be able to say an ul has these children, where our spec explictly forbids it
they would also have to subclass ul into their spec
jd: I'm ok with your proposal and aria-owns having the same funcitonality
jemma: are we taking care of the epub issue?
jn: its a similar issue but it is not the same
<Jemma_> https://github.com/w3c/dpub-aria/issues/15
mk: lets conceptual discuss how to solve the dpub issue
should we have explicit spec prose about how to extend aria?
jn: AT would have to support this
<joanie> https://w3c.github.io/dpub-aria/#doc-biblioentry
jd: the link I just put in
superclass role of .biblioentry is a list item
now dpub-aam
<joanie> https://www.w3.org/TR/dpub-aam-1.0/#role-map-biblioentry
this goes one step forward and says it exposes on all platforms as a list item. In the mapping it says that it is a biblioentry
some platforms communicate that
<Jemma_> https://w3c.github.io/dpub-aria/#doc-biblioentry
AT automatically support these subclassing
the problem with the extension spec is that the modifications to the list item made by biblioentry is in violation of the aria spec for required owned elements of list
vy: We need to change the spec to allow this scenario
jd: yes that is right
<Matt_King> What the spec says about extensions: The use of RDF/OWL as a formal representation of roles may be used to support future extensibility. Standard RDF/OWL mechanisms can be used to define new roles that inherit from the roles defined in this specification. The mechanism to define and use role extensions in an interoperable manner, however, is not defined by this specification, and RDF/OWL...
<Matt_King> ...processing is not essential to interoperable implementation of this specification. A future version of WAI-ARIA is expected to define how to extend roles.
mk: if we put any extension language in our spec right now, then do we need to change what it says here about how to extend roles?
jd: no because we still haven't defined how to extend roles
mk: if we add some language to the section about required owned elements and that language specifically says that if an extension subclasses a role, then that extension may define the required owned elements for that role?
<ZoeBijl> scribe: ZoeBijl
JN: could we just say just for the list role
are there other subclasses of listitem
treeitem is a subclass of listitem as well
<BGaraventa> I'm on the call as well
or we could have a different subclass
<BGaraventa> :)
there’s spec level subclasses and extension level subclasses
MK: That’s what I was saying
JN: It seems a bit hacky. but it works
<sarah_higley> wave! :)
MK: We don’t have anything else for making rules
I fear it’s a can of worms
JN: Sounds like a 1.3 topic o me
MK: Maybe we should post, have this issue
considering 1.3
I don’t think we should try to fix this in 1.2
Because we don’t know all the ramifications of it
We already have modeules
But we have nothing that governs them at all
JN: Is there another way to fix this?
JD: They could add a numeral, but they don’t want that
JN: They have a dpub-list which extends list
<sarah_higley> I don't see an issue with saying they should extend list
MK: I thought they had list?
They have listitem
That just means that in their markup, in their spec, all their implementations that instead of their bibliography
JD: Yeah but the bibliography is the whole thing
It has more stuff in it
MK: Whatever their ul is, they should have a bibliolist
If we were going to solve it it would be a 1.3 issue
JN: So we should ask ourselves (or them) if there are additional issues
If there are we should definitely move it to 1.3
MK: Either fix in DPUB 1.1 or we take a year to fix it in ARIA 1.3
ZB: W3C Nu Validator doesn’t throw an error on this.
aXe 3.9.0 does
<BGaraventa> I got lots of energy
https://github.com/w3c/aria/issues/1001#issuecomment-517806506
github: https://github.com/w3c/aria/issues/1001#issuecomment-517806506
MK: there’s a few things that we’d like to cover
but the ultimate goal of this is for me to walk away with some notion of whether or not the group supports some new more end user friendly approaches to helping web developers learn about accessibility from W3C resources.
HTML and potentially WCAG
But let’s discuss it among our selves frist
We need to know what this groups wants to support
I’m thinking about the multi year picture
But not less than two
But preferably a lot longer
So I want to talk about the problem
before we do that tho
I want to make sure everyone is up to date
particular the APG and the ARIA AT
APG does not yet explain all of ARIA
all of the new ARIA 1.2 stuff will be in APG 1.2
we have a new “role” coverage
Same for states and properties
So we can better explain what we have covered
But when it comes to guidance with example we have long way to go
So there’s a lot of work to do on the APG itself
My original goal is to close that gap by the end of the year
It’s realistic to think we can achieve this by the end of next year
especially with the help of Boaz’ team
have a more standard PR review process
trying to beef up that APG TF operates
so it can fulfill its mission
A big problem with the APG is that it does not help people make stuff that works with all the bugs that exist in all the AT and browsers out there.
It’s not a component library you can just grab components from and drop in your project
It’s a resource of how ARIA should be used
if AT and browsers didn’t have any bugs it would be a component library
If someone comes to the APG and thinks they can use it without testing it has a bad influence on the end users experience
providing support tables is not in the scope of the APG
That’s why we now have the ARIA AT CG
Its goal being to provide support tables or a supported score that would give some indication of how well supported these examples are
I’d like to give Val some time to discuss our progress
Val: we joined in because of our background in testing
we have two goals
one is to design a test suite
for the APG and ARIA in general
designing a test suite is a big task because there are a lot of implications and difficulties
so we need a way to write test that can be understood by users and AT
We also need a document that describes how AT should behave
Such a document does not exist
So we’re also talking to AT companies to create such a thing
Designing a test suite is a huge bulk fo the work
As it is right now we’re breaking down the design patterns in the APG
into a bunch of expectations
The second goals is designing a test harness that assert these tests to manual testers
We’re not sure how much time and how frequent we can test
Bocoup and Facebook are working on this together
we’re trying to lock down the design for this test suite
In november we’ll build a prototype
that’s the timeline right now
<Jemma_> Timeline is finishing the design by the end of Oct, and delivering the product by the end of November.
<Jemma_> +q
JK: Part of my question was answered already
it was about timeline and the goals
I think it’s pretty tight
The last AT meeting I joined there was a table of AT and browser combinations
What does the final product look like?
MK: End of november is only the test harness
Val: yeah, it’s a prototype
We might start to record results
we won’t have a full suite
we want to have some initial tests
but it won’t have enough for a full suite
it won’t be robust enough
we’ll have to run test first
MK: This is an exploratory prototype
To see what kind of issues we’ll run into and how we can fix those
JN: What other kind of documents (other than APG and ARIA AT) do you have in mind?
MK: There are a lot of different W3C resources related to helping a web dev make stuff accessible
some is almost duplicated
but some are maintained by different groups
<Jemma_> s/strick/tight
<Jemma_> https://www.w3.org/TR/using-aria/
<Jemma_> https://www.w3.org/TR/html-aria/
the list of resources, the big buckets, are APG, ARIA AT both from ARIA WG, Using ARIA (from the WPWG),
ARIA in HTML (also from WPWG)
<Jemma_> I think we should define what we meant by "explanitory resources" precisely.
WAI Tutorials
from EOWG
not sure to what extent that covers WCAG techniques
they’re ment to be explanitory resources
<Jemma_> +q
The problem I see with all these resourcesw
there’s important information in all of them
they need to be known by the same people
from our perspective we can say that’s your groups scope, this is our goup’s scope, etc
clear for us at the W3C, but not from the outside
there’s confusion outside of the W3C.
Sometimes the resources say different things.
We need to look at how we can serve the community
that best servers their purposes
maybe there should be a community group that sucks up all of these resources
that forms a format that can combine all of them
I like how the WAI tutorials are represented on their own site
Why not have something similar for all of these resources
That’s the question I would like to put forward to the group
JN: I agree that it should be a website
Boaz: it should be like a bootstrap thing
MK: I would love fort there to be tutorials that explain our choices for a design pattern step by step
<zcorpan> scribenick: zcorpan
jamesn: as soon as you take
accessibility practices
... you take away aria practices, since aria may not be the
best way to solve a11y problems
Matt_King: encapsulating all of
aria in apg is part of the scope of the new rename
accessibility practices
... debate of the name
... and scope
... if we rebrand scope, tutorial is not just about aria
Boaz: accessible practices
jamesn: so that is beyond scope
of this group
... if our pages are in a similar.. .can be integrated with
theirs
Boaz: what's your preference for merging these things into a more coherent resource
jamesn: if they merge we can't own them
Matt_King: there are joint task forces
jamesn: there could be something like that
Matt_King: joint TF can have as part of its scope explaining the aria spec
jamesn: yes
Matt_King: it would have to have aria representation, aria wg would be a stake holder
Boaz: no matter how governance is in terms of ownership and scope, we need to talk to web platform wg or whatever about do we want to delete "using aria"
Matt_King: if it was mdn there would be a governance issue there too
Boaz: maube there could be a way to have that scope in APG, done by aria, in a way that can be consumed by e.g. MDN
Matt_King: next step in exploration?
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/Ia gree/I agree/ Succeeded: i/HTML Accessibility Issues/scribe: tink Succeeded: s/????/I think the idea here is to change web developer's mindsets/ Succeeded: s/decision/description/ Succeeded: s/than/unlike/ Succeeded: s/than/unlike/ Succeeded: s/ground/group/ Succeeded: s/strike that/strike the language about going to links/ Succeeded: s/issue/issue dpub-aria #14/ Succeeded: s/#14/#15/ FAILED: s/#14/#15/ Succeeded: s/descriptions/restrictions/ Succeeded: s/descriptions/restrictions/ Succeeded: s/have to/have to tree prune/ Succeeded: s/support it/support these subclassing/ Succeeded: s/for list item/for required owned elements of list/ Succeeded: s/aXr/aXe/ Succeeded: s/apg/APG/ Succeeded: s/see/explain/ Succeeded: s/TF/CG/ Succeeded: s/suitte/suite/ FAILED: s/strick/tight/ Succeeded: s/group/groups/ Succeeded: s/strict/tight/ Present: Avneesh Benjamin_Young Boaz_Sender Bocoup CharlesL David_Burns Irfan Jemma_ Joanmarie_Diggs Mozilla ZoeBijl achraf jamesn mhakkinen spectranaut Bryan_Garaventa Boaz zcorpan Found Scribe: ZoeBijl Inferring ScribeNick: ZoeBijl Found Scribe: tink Found Scribe: ZoeBijl Inferring ScribeNick: ZoeBijl Found Scribe: spectranaut Inferring ScribeNick: spectranaut Found Scribe: ZoeBijl Inferring ScribeNick: ZoeBijl Found ScribeNick: zcorpan Scribes: ZoeBijl, tink, spectranaut ScribeNicks: zcorpan, ZoeBijl, spectranaut WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]