) defines a section of a document to indicate a related grouping of semantic meaning. It makes sense to use the section element to provide extra context for the parent element. 14:41:13 Jennifer_strickland_: we need to consider what the actions are 14:41:21 present+ 14:41:24 -1 to having too many headings 14:41:27 q+ to ask if better definitions are sufficient, or should we have technology neutral rules at the Outcome level? 14:41:35 q? 14:41:48 Sheri_B-H_: example is a survey -- examples of text then some buttons to select 14:42:03 Sheri_B-H_: so every section we need headings 14:42:11 Jennifer_strickland_: better headings definition could help 14:42:20 https://html.spec.whatwg.org/multipage/sections.html#the-section-element 14:42:32 Q+ 14:42:46 The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading. 14:42:54 Proposed: A section contains controls or information grouped by a theme or purpose which is distinct from the themes or purpose of other sections within a view or process. 14:43:13 Jennifer_strickland_: phps we need to be requiring a heading per page 14:43:13 q? 14:43:18 ack b 14:43:18 bruce_bailey, you wanted to ask to look at current HTML def for section 14:43:57 bruce_bailey: think our concepts are actually html, even though we hope can be applied beyond html 14:44:11 ack j 14:44:35 jeanne2: asking whether more precise definitions would help the ACT level 14:44:49 q+ 14:44:50 jeanne2: or do we need rules at the tech neutral level 14:44:54 Yes to Jeanne's question 14:45:09 q? 14:45:17 ack jeanne 14:45:17 jeanne, you wanted to ask if better definitions are sufficient, or should we have technology neutral rules at the Outcome level? 14:45:22 q+ 14:45:33 jf: concerned that too many headings will have a negative impact on some users 14:45:48 q- 14:46:10 Bruce, Section in PDF Spec: A container for grouping related content elements 14:46:17 jf: think we need appropriate titles/labels, but not nec a heading 14:46:22 The section element is a neutral HTML element, and the definition we're discussing here as sectioning is a bit different. The section element in html has only minimal difference from a div, for example. 14:46:30 q? 14:46:31 Sheri_B-H_: not advocating, just trying to extend Chuck's suggestion in the moment 14:46:34 ack anne 14:46:45 q+ 14:46:50 Jemma: not sure we need rules on the outcome level 14:47:01 q+ to say I'm a fan of Bruce's comment. No need to create new definitions. And to ask about how WCAG 2 handles this. 14:47:16 Jemma: but we need some kind of definition in the outcome 14:48:02 Thanks, Anne, that is very helpful 14:48:15 s/anne/jemma/ 14:48:33 Wilco: ACT ruiles tend to work best when normative requirements are well defined 14:48:43 q+ to say yes to definitions in outcome 14:48:54 +1 14:48:58 ack w 14:48:59 ack ch 14:48:59 Chuck_, you wanted to say I'm a fan of Bruce's comment. No need to create new definitions. And to ask about how WCAG 2 handles this. 14:49:05 +1 to wilco 14:49:09 +1 to wilco 14:49:17 Q+ 14:49:23 +1 to Wilco - clearly defined Outcomes is critical 14:49:39 mbgower has joined #wcag-act 14:49:41 Chuck_: if we need clarity for purposes in the outcome ... redefining existing definitions may be problematic 14:49:45 present+ 14:50:09 q+ 14:50:11 Chuck_: we need not regress, but not necessarily improve 14:50:27 ack ka 14:50:27 kathyeng, you wanted to say yes to definitions in outcome 14:50:27 Chuck_: It's not imperative to do better 14:50:49 kathyeng: Agree on helpfulness of definitions; hard for test authoring 14:51:07 kathyeng: the more well defined the definition; the easier to write test 14:51:13 ack jen 14:52:13 +1 to focusing on "semantic" structure (versus just "sections") 14:52:18 I would like to warn that we don't want to define by HTML, we have to be technology neutral 14:52:26 Do all (a sectioning element) require a heading? 14:52:30 ack sh 14:52:32 Yep. 14:52:59 shadi: more testability was one goal of wcag3 14:53:16 q+ 14:53:23 (Yep was a response to Jeanne re tech neutral; would not be a response to JF) 14:53:26 shadi: known issues should be improved -- better definitions so better rules 14:53:38 jeanne2: asks about definitions in tech neutral 14:53:52 shadi: worried about definitions to support testability 14:53:55 q+ to ask about Jeanne's proposed resolution 14:53:58 Q+ 14:54:10 q- 14:54:24 david-macdonald_ has joined #wcag-act 14:54:36 present+ 14:54:37 +1 to Shadi's comments though 14:54:51 ack ch 14:54:51 Chuck_, you wanted to ask about Jeanne's proposed resolution 14:55:10 Chuck_: looks like def tailored to support the outcome 14:55:24 Chuck_: support the concept--but should we call that out? 14:56:09 jeanne2: agrees defs could be specific to outcomes and would allow more precision at tech neutral level 14:56:13 q? 14:56:20 jeanne2: like that idea 14:56:30 ack jf 14:56:49 jf: Want to +1 the idea of semantic 14:57:20 jf: believe we're trying to ensure strong semantic structure in whatever content we're reviewing 14:57:46 kathyeng: the more well defined the definition; the easier to write test 14:58:04 rrsagent, make minutes 14:58:04 I have made the request to generate https://www.w3.org/2021/05/14-wcag-act-minutes.html mbgower 14:58:26 need to drop for a client / customer meeting. Great work by all! 14:58:52 I'm here now and can speak to my points 14:58:55 Wilco: my second comment is on consistency ... phps should be more clearly spelled out 14:59:12 Wilco: also why only headings? There are other mechanisms 14:59:35 Jennifer_strickland_: agree all needs reviewed and further developed 15:00:36 Wilco: notes organizing text doc is one kind of content; but there are others 15:00:56 @wilco, or maybe not. And let's not forget

15:01:01 Jennifer_strickland_: I think heading in this group are automatically thinking or

15:01:23 Jennifer_strickland_: those may have different definitions depending on the tech involved 15:01:53 and a) ARIA is intended to be tech-neutral, b) ARIA sematinces override native semantics. I realize this is part of "testing", but still... 15:01:53 Sheri_B-H_: but that suggests not using different definitions for commonly understood terms 15:02:08 q+ 15:02:27 ack br 15:02:51 bruce_bailey: suggests trying to use words similar to headings that are familiar -- at least for now 15:03:01 q+ 15:03:12 q+ 15:03:19 ack da 15:03:21 bruce_bailey: words not appropriated by html elements might be a good approach 15:03:43 david-macdonald_: recalls we had talked about web unit 15:04:04 david-macdonald_: recalls the adoption of "horsepower" 15:04:18 david-macdonald_: this to say that terms can survive into a different context 15:04:38 +1 to DAvid - this is touching (a bit) on "Plain Language" 15:05:00 david-macdonald_: if we have real examples of using something other than headings, that would be helpful 15:05:34 The Method lists exceptions of when the heading would not be needed 15:05:42 with apps, could have window TITLE that serves as HEADING 15:05:50 scribe: trevor 15:06:45 jennifer_strickland_: want to call out the way we are using certain words in our outcome language at the beginning to inform how we refer to things. doing some user research w/ lay-people might be very helpful 15:07:25 q+ to say there are 500 years of typographic convention 15:07:28 jennifer_strickland_: we all think headings and title and labelling is how we talk about these. but what does a novice web dev or QA person think. the verbiage they use may be more plain language 15:07:33 q+ 15:07:41 ack jen 15:07:45 ack mb 15:07:45 mbgower, you wanted to say there are 500 years of typographic convention 15:08:29 mbgower: I think that type of convention is very much in what david was saying. title on the outside of the book, heading marks the topic of content 15:08:46 +1 to Mbgower 15:08:58 Q+ to note that "heading" has already been normatively defined by WAI - https://www.w3.org/TR/wai-aria-1.1/#heading 15:08:58 +1 to MGower 15:09:01 mbgower: Going back to that seems to be a good way forward, most easily understood coming from a print background 15:09:17 q+ 15:09:26 wilco: want to get a bit away from this, but think it something valuable to explore 15:09:35 question+ Finding the right word for a definition is important? 15:09:43 ack an 15:09:44 jeanne: finding the right words is important 15:10:16 ack jf 15:10:16 JF, you wanted to note that "heading" has already been normatively defined by WAI - https://www.w3.org/TR/wai-aria-1.1/#heading 15:10:23 anne_thyme: for the people writing these outcomes, recommend looking at the glossary list of the act rules repo since it will help with the things not defined in current wcag 15:10:23 https://www.w3.org/TR/wai-aria-1.1/#heading 15:11:01 JF: We already have a normative heading definition from aria. question is if we accept that definition or create a new definition. Think that we shouldn't reinvent the wheel 15:11:12 Thanks, Anne - very helpful. Can you drop a link to that so we can add it to the style guide? 15:11:16 ack ca 15:11:24 A heading for a section of the page. 15:11:38 Often, heading elements will be referenced with the aria-labelledby attribute of the section for which they serve as a heading. If headings are organized into a logical outline, the aria-level attribute is used to indicate the nesting level. 15:12:04 CarlosD: Wanted to bring attention with why headings are the only way to locate content. Whitespace is a way to organize, heading is a way to organize and describe content, so don't think headings are the only way to do this 15:12:40 jeanne2: thats a good point, the examples in the method show how to use whitespace in a text-only document. wondering if it should be at an outcome level 15:13:35 +1 to Wilco 15:13:37 https://www.w3.org/TR/wai-aria-1.1/#section 15:13:45 wilco: my last point on "makes locating and navigating info easier and faster", putting in normative means that headings actually make something easier or faster. I don't think that is part of the intent and so shoulnd't be normative 15:13:47 question+ Should examples atthe Method level move to the Outcome level? The example is using white space to to separate content. 15:13:47 +1 to Wilco 15:13:49 +1 to Wilco -- this belongs as background/rationale 15:13:51 A renderable structural containment unit in a document or application. 15:13:59 +1 to wilco 15:14:13 Note: section is an abstract role used for the ontology. Authors should not use this role in content. 15:14:25 jeanne2: Aron comment, logical blocks and expected headings need more definition 15:15:12 jeanne2: Jennifer Chadwick question on functional categories compared with functional needs. 15:15:35 MichaelC: no, they are making a clear distinction between them. we will have more to explain to the group soon 15:16:37 jeanne2: janina asked about other semantics serving the same purpose as headings 15:18:24 janina: know of many examples where there can be a mixture. I think it can go all the way back to views and accessibility support. Perhaps more requirements on AT. 15:20:14 anne_thyme: question on what types of headings, visual, semantic, or both. Think they are a lot more than the aria-definition. Was not clear how to test outcome just from description. Many different interpretations 15:21:27 q+ 15:21:34 jeanne2: We do have other outcomes for visual and semantic headings. This was common to both. Would it be better to have that be part of the outcome on visual and semantic headings, or have basic concept that is extended 15:22:17 q- 15:22:42 From 2.4.6 Headings and Labels: "This Success Criterion also does not require that content acting as a heading or label be correctly marked up or identified - this aspect is covered separately by 1.3.1: Info and Relationships. " 15:22:57 anne_thyme: I think it just needs to be clear that it applies to both. For rating could be hard to count with different number of visual and semantic headings 15:23:17 q+ 15:23:24 +1 to Anne 15:23:31 q+ 15:23:32 +1 to Anne 15:23:40 anne_thyme: Need to know number of objects that are included for counting to get consistent scoring 15:24:19 question+ How to include the counting for scoring and the way different circumstances can be counted. What to do when the count is not the same across different outcomes? 15:24:24 sheri_B-h_: Been spending a lot of time with ML with headings but do believe we can automate solutions for some of those. 15:24:47 lol, not all of them Bruce 15:25:04 anne_thyme: Nice to hear it may be able to be automated, but need to make sure the different automated tools get same results. Goal of ACT-Rules 15:25:11 s/lol, not all of them Bruce// 15:25:11 q? 15:25:12 Q+ to speak to tests and scores 15:25:25 ack sh 15:25:28 Sheri_B-H_: hoping to say that once we get the solution we can automate so everyone gets the same result 15:25:33 ack da 15:26:03 qv? 15:26:05 q+ to ask if ACT rules do this now for WCAG 2 headings 15:26:22 +1 to davids comment, i am now not a fan of tallies 15:27:09 q+ to say that without more clarity on the conformance model I think that it is premature to say that there is general agreement on counting things. 15:27:20 david-macdonald_: Has concerns about the counting the number of passing events for headings. It seems like it would double or triple the amount of time needed to check headings. 15:27:41 david-macdonald_: would increase cost to company and if budget stays the same could negatively impact accessibility. 15:28:10 q+ to say counting might be ACT related 15:28:27 We can explore options for that in the upcoming AG work 15:28:33 ack jf 15:28:33 JF, you wanted to speak to tests and scores 15:29:25 JF: When we get to ACT tests, not all tests are applicable in all instances. Native mobile apps don't have notion of different levels of headings. Would be running different tests compared to web. 15:29:53 JF: Think about ACE EPUB tool that shows hierarchy and potentially shows missed headings. 15:30:21 ack ch 15:30:21 Chuck_, you wanted to ask if ACT rules do this now for WCAG 2 headings 15:30:28 JF: We have a high level requirement for headings that are understood and methods and we need to keep those notions separate. 15:31:08 Chuck_: Does ACT have tests that help identify if headings organize content 15:31:28 Wilco: Nope, we have other rules for headings, but not for this 15:31:33 q? 15:31:54 ack awk 15:31:54 AWK, you wanted to say that without more clarity on the conformance model I think that it is premature to say that there is general agreement on counting things. 15:31:57 ack br 15:31:58 bruce_bailey, you wanted to say counting might be ACT related 15:32:30 bruce_bailey: Not quite ready to drop tally counting. One of the big differences between ACT and Trusted Tester is that ACT really tries to be machine countable. 15:32:41 johnkirkwood has joined #wcag-act 15:33:26 Wilco: As a clarification, ACT rules don't need to be automated and several are not automatable. 15:33:31 zakim, take up next 15:33:31 agendum 2 -- Rating & Critical Errors sections of Headings organize content -- taken up [from jeanne] 15:33:50 questions? 15:34:21 Does every test unit (view?) require at least 1 heading 15:34:57 jeanne2: Have collected questions from this discussion 15:35:09 Jeanne should refresh survey 15:36:58 q+ 15:37:09 Thank you, Wilco, for clarification on ACT. 15:37:17 q- 15:37:31 q+ 15:37:42 q+ 15:37:43 jeanne2: put up proposal for defintion (see above) 15:38:08 AWK: so the resolution is saying that the outcomes need to have definitions not that they are good right now? 15:38:52 jeann2: yep exactly, we are trying to take a specific example and generalize to the rest of the document. In this case we are talking about creating precise and testable definitions. The definitions may be customized per outcome 15:39:23 jeanne2: want to work with ACT to ensure good definitions that are testable 15:39:32 q+ to say "customizable" definitions may have issues. 15:39:46 ack awk 15:39:59 AWK: So outcome and questions would both be normative? 15:39:59 ack sh 15:40:02 jeanne2: yes 15:40:03 q+ to say that I didn't see outcomes themselves as necessarily directly testable, but rather defining what the technology-specific tests would need to document 15:40:44 shadi: part of the phrase "at the technology nuetral level", its not really assisting testing, not sure there is tech agnostic testing 15:41:29 shadi: feel there is a bit too much focus on testing. we also want this for developers to know what to do 15:41:30 If content is organized into sections visually that would be tested using technology-neutral tests. Like General techniques today 15:41:34 q- 15:41:37 +1 15:41:50 +1, Shadi covered my point better than I would have. 15:42:19 ack chuck 15:42:19 Chuck_, you wanted to say "customizable" definitions may have issues. 15:42:56 Chuck_: I think there are some problems with creating our own definitions. Perhaps worth exploring if the definitions are technology specific. But need to be very careful 15:42:56 [[That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise.]] 15:43:32 jeanne2: Agree and think that the best way will be for us to try it out. Hoping to prototype it for the meeting next week 15:44:17 shadi: Put updated proposal above 15:44:25 question+ How to prototype the definitions so that we can see if customizable definitions work. 15:45:35 Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise. 15:45:51 +1 15:45:56 +1 15:45:56 +1 15:45:56 +1 15:45:57 +1 15:45:57 +1 15:45:59 +1 15:46:00 +1 15:46:00 +1 15:46:01 +1 15:46:01 +1 15:46:02 +1 15:46:02 +1 15:46:03 +1 15:46:05 q+ 15:46:06 +1 15:46:07 +1 15:46:10 +1 15:46:14 +1 15:46:23 +1 15:46:32 q+ 15:46:34 +1 to Bruce's point!! 15:46:36 ack br 15:46:40 bruce_bailey: +1 on that, but also ask that the resolution include not having terms conflict with aria 15:46:48 +1 to Bruce's point 15:46:50 I presume that is part of the working with Silver + ACT to define terms. 15:47:02 Q+ 15:47:20 ack w 15:47:26 Wilco: I think that is going to be very difficult. Headings is defined in aria and this outcome for WCAG 3 would not work as well with the same definition. Good to keep in mind, but don't think we can definitively say. 15:47:26 q+ 15:47:30 q+ 15:47:35 Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will try to avoid conflicts with existing definitions. 15:47:54 q+ 15:48:04 -1 to Try 15:48:10 Q+ to also request that the definitions never conflict with PDF spec definitions 15:48:10 q+ to respond to definition 15:48:21 q+ 15:48:36 bruce_bailey: Looking for weakest form of compatibility. 15:48:47 Chuck_: Proposed new resolution (above) 15:48:52 Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will attempt to harmonize with existing definitions. 15:49:08 bruce_bailey: Looking for harmonization for not to conflict 15:49:13 this is a scoping discussion 15:49:28 characterization we used to use is "harmonization" 15:49:40 jeanne2: we are going to try over the next week and see how it goes. 15:49:42 q- my point is that "trying" could easily include documenting diffs 15:49:47 q? 15:49:50 q- 15:50:14 but our experience with 508 reg writing is that we only really need "does not conflict with" 15:50:26 Chuck_: Everyone +1'd the first proposal, bruce could you live with the first proposal 15:50:27 -1 it is not complete enough 15:50:43 does not contradict? 15:51:03 shadi: instead of not conflict with, could we have explaining the relation to others in case we have to contradict 15:51:10 +1 to Shadi's principle noting that ARIA is screen reader specific 15:51:27 Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will document relationships to existing definitions. 15:51:44 Please no more jumping queue. It is not fair to those of use following the rules of engagement. 15:52:08 jeanne2: I like the approach, it gives us a lot more flexibility. 15:52:54 q- 15:53:19 JF: Generally i think shadis proposal is better. This is a conflict resolution, don't want to redefine words that have existed for decades 15:53:45 present+ 15:53:52 ... like showing the relationship but don't want to redefine. 15:53:54 ack JF 15:53:58 ack Jenn 15:54:34 +1 this is a very complicated topic 15:54:56 jennifer_strickland_: I don't think we will able to come back with good definitions w/ ACT in one week. 15:55:40 ... more useful to include more diverse experiences in definitions 15:56:29 +1 to Jennifer's point 15:56:37 +1 15:56:57 +1 to not over-require a one week deliverable 15:57:07 jeanne2: wanted to experiment with the customizing of terms for different outcome. certainly not a final definition 15:57:15 Thank you! <3 15:57:25 ... withdraw on suggestion since people think this will be hard 15:58:10 i can live with inconsitency 15:58:17 +1 15:58:17 ack a 15:58:17 AWK, you wanted to also request that the definitions never conflict with PDF spec definitions 15:58:18 +1 15:58:21 AWK: like shadis proposal. concern with trying not to contradict other definitions. for technology agnostic will have to look at many things and can't guarantee no inconsistency 15:58:57 Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will document relationships to existing definitions. 15:59:05 +1 15:59:11 +1 15:59:15 +1 15:59:15 +0 15:59:16 +1 15:59:17 +1 15:59:22 +1 15:59:22 +1 15:59:24 +1 15:59:24 +1 15:59:24 +1 15:59:25 +1 15:59:25 +1 15:59:28 0 15:59:30 I would like to see something about not redefining or creating conflict 15:59:50 +1 15:59:58 0 16:00:16 I think that is addressed with the 'document relationships to existing definitions' but your mileage may vary. 16:00:16 +1 16:00:35 Proposed Resolution: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, and will document relationships to existing definitions to avoid conflicts. 16:01:03 JF: Would like to be aspirational and bring things together but that it does not become normative. 16:01:12 Definitions are normative. Avoiding conflicts with other document's definitions is the aspirational part. 16:01:51 "That the Outcome (technology neutral) level of WCAG3 have definitions of key terms that are aspirational, but is not in itself normative. 16:02:11 Proposal: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, document relationships to existing definitions, and endeavor to avoid contradictions with terms defined by WAI-ARIA, HTML5, and related standards. 16:02:42 Have we ever tried to schedule rotating scribes? 16:03:22 scribe: Chuck 16:03:30 endeavour sounds like a SHOULD, I'd prefer a MUST 16:03:53 (ref: RFC 2119) 16:04:38 Jennifer: It would be good to share the responsibility. 16:04:44 Jennifer: of scribing. 16:05:12 Jeanne: Recap Bruce's proposal. 16:05:42 Jeanne: 16:06:01 JF: Definitions of "should" and "must". 16:06:23 JF: Strike "endeavor to avoid", and make it "will avoid". We need to succeed. 16:06:24 Proposal: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, document relationships to existing definitions, and endeavor to avoid contradictions with terms defined by WAI-ARIA, HTML5, and related standards. 16:06:38 Proposal: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, document relationships to existing definitions, and avoid contradictions with terms defined by WAI-ARIA, HTML5, and related standards. 16:06:43 Jeanne: We are trying to capture ideas, this is word-smithing. 16:06:50 I think it's useful for holding our feet to the fire. 16:06:51 JF - "The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119]." 16:06:53 -1 to JF's proposal. We're talking about a draft deliverable due in a week 16:06:55 Jeanne: 16:07:11 We are not delivering this in a week. 16:07:26 Jeanne: 16:07:40 +.65 (I can live with) current proposal 16:07:46 Is PDF a "related standard"? 16:07:58 Silver structured content sub-group can't deliver it in a week. Unless I'm missing something. 16:08:05 bruce_bailey has joined #wcag-act 16:08:34 STONG -1 to endevour 16:08:38 Jeanne: Once we say "we absolutely will avoid" will tie us in knots. I want to go back to Bruce's proposal. This is not an issue we are deciding for all time, we are trying to work incrementally forward. 16:08:46 s/STONG/STRONG 16:08:56 Proposal: That the Outcome (technology neutral) level of WCAG3 have definitions of key terms. Silver will work with ACT to ensure definitions are precise, document relationships to existing definitions, and endeavor to avoid contradictions with terms defined by WAI-ARIA, HTML5, and related standards. 16:09:33 +.9999, we are "trying" this out. 16:09:36 +1 16:09:37 -1 16:09:37 -1 unless we make the list of specs to avoid contradictions is genericized. 16:09:37 +1 16:09:39 +1 16:09:43 +1 16:09:45 +1 16:09:45 Jeanne: +1 if you can accept, -1 if you can't live with. 16:09:49 +1 16:09:49 +1 16:09:51 +1 16:09:51 +1 16:09:51 +1 16:09:52 +1 16:09:56 +1 16:09:58 +1 16:09:59 q+ 16:10:00 to AWK comment, PDF is a related standard 16:10:01 +1 16:10:12 in my view 16:10:19 +1 16:10:20 +1 16:10:27