Meeting minutes
Announcements
maryjom: Still trying to come up with our language, then will go to AGWG for broader review
… Changes are needed in the EN anyway
Mike_Pluke: I could include anything that looks good
maryjom: EU and other countries are changing their time this weekend.
… For one week, the next meeting will be at 10AM Eastern, an hour earlier for those countries
… The following week the U.S. changes time, things will sync up again
1.3.4 Orientation
<maryjom> Link to issue 779: w3c/
<maryjom> Link to PR 780: w3c/
<maryjom> Link to Google doc: https://
maryjom: Google doc contains several proposals that have been discussed
GreggVan: I just fixed one wrong thing that I had
… We have the "designed to be" and it shouldn't be there
Daniel: Change ipad to tablets, please. We don't use to do brands
GreggVan: Done.
<maryjom> POLL: Which proposal do you prefer? 1) The current PR 780, as-is, 2) PR 780 with Daniel’s proposed changes, 3) Gregg’s proposal, or 4) something else
Daniel: we should also fix spacing
GreggVan: Rist watch -- if you are writing it for it to be used while charging you should meet, other wise if you are writing it for normal use you wouldn't
<GreggVan> 3
<loicmn> 3
3
<Mike_Pluke> 3
Mike_Pluke: The text at the beginning of the example doesn't match with the last part of the requirement
GreggVan: Should be "is", we shouldn't talk about the future
… If you are writing software for the watch not to be used for sleep mode, the hardware is only on one orientation. The software is never used ... it's correct that the two should match
maryjom: You previously had numbered examples, now I've moved them to bullets as they're easier to read
<PhilDay> Apologies from me for my extremely tardy entrance...
<maryjom> Proposal 3 text:
<maryjom> Applying SC 1.3.4 Orientation to Non-Web Documents
<maryjom> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4, except for non-web documents that will never be displayed on hardware that is reoriented in typical use.
<maryjom> Example (Added) (for non-web documents): Examples of non-web documents that will never be displayed on hardware that is reoriented in typical use would be
<maryjom> a building directory that is only displayed on displays (of any type including tablets) that are all fixed to the wall in one orientation,
<maryjom> reports of results of a test that are displayed only on the screen of the testing device, and
<maryjom> the status report sent to the screen of a copy machine (but not the status report that would be sent to a web interface to the same machine).
<maryjom> Applying SC 1.3.4 Orientation to Non-Web Software
<maryjom> This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4, except for non-web software that will never be displayed on hardware that is reoriented in typical use.
<maryjom> Example (Added): Examples of non-web software that will never be displayed on hardware that is reoriented in typical use would be:
<maryjom> software for a typical calculator that does not support screen re-orientation,
<maryjom> software menus and controls on a copier or other device that is not intended to be viewed in more than one orientation (but not any remote control software or app for the same device that runs on computers or mobile devices),
<maryjom> software on a wristwatch that is not intended to be viewed when the watch is not on the wrist, and
<maryjom> special applications such as software for displays around a building that will only be used on a known set of displays that are all permanently affixed in the same orientation.
<maryjom> Note (Added) (for non-web software)
<maryjom> See also the Comments on Closed Functionality.
<maryjom> DRAFT RESOLUTION: For SC 1.3.4, incorporate proposal 3 as shown in the minutes above.
<loicmn> +1
<Mike_Pluke> +1
<PhilDay> +1
<GreggVan> +1
RESOLUTION: For SC 1.3.4, incorporate proposal 3 as shown in the minutes above.
<Daniel> +1
2.4.2 Page Titled
<maryjom> Link to issue 627: w3c/
<maryjom> PR 793: w3c/
<maryjom> Google doc link: https://
Google doc has all the current proposals in 1 place
Discussion about the use of "style" in proposal 3
Daniel: Attribute is also misleading - element may be more appropriate
Daniel: Could make it longer "title that is possible to be exposed to assistive technologies in the platform software" or some similar explanation.
GreggVan: Title of a movie fails WCAG. It does not always give title or purpose of the movie
… It can't be style - in a PDF you would change the title attribute which is in the metadata.
… Problems we have. 1) As long as the technology supports programmatically determinable title.
… 2) Need to have it be page oriented otherwise we have other technologies (like SVG) which could have metadata, but that might never be useful for AT - it will never be read by others.
… 3) Wherever we put this is not the name - as name does not automatically pass
Originally it was talking about the title of the "window" - maybe it is more about the uniqueness of the label / title
Mike_Pluke: Agree with Daniel & Gregg - need to emphasise the programmatically determinable element / attribute.
… If that is the case, then the information that is put in that is just the same as it would be for a single web page.
… If AT can read the titles for non page oriented files like graphics - if it can, then we should lose this as it is potentially confusing
Daniel: +1 to remove page oriented. If we want to exclude SVG and others then that is less broad than any non page oriented.
… WCAG does not define title as being programmatically determined.
… This may therefore be an underlying WCAG question.
As long as you can read the title with AT - then it passes even if the title doesn't have meaningful topic or purpose - it just describes the title, doesn't need a synopsis.
GreggVan: Now back to the beginning of the discussion - whatever the author decides to name it - that passes
Daniel: Describe the topic or purpose
GreggVan: A name like "Z" does not desribe the topic or purpose
… Maybe all we are saying is that if there is a title attribute then it must be populated - and that will therefore pass
web pages have a title that describes either a topic or purpose. Doesn't specify what is meant by topic or purpose
<loicmn> The only reference we have to non-valid titles in WCAG is failure F25 (https://
GreggVan: Could say it needs to be programmatically determinable, and then add name, topic or purpose
… Could say name, title or purpose. Then we could leave the underlying issues to WCAG3 to fix
Daniel: +1 to the idea of programmatically determinable - but maybe not the words.
GreggVan: Didn't say programmatically determinable for title of web page - as it was self explanatory. That's not the case for non-web software or documents
GreggVan: Think that saying name, title or purpose would be a suitable fix
Mary Jo has been trying to modify the language based on the discussion.
2.4.2 Non-web Document Titled: Where a non-web document is page-oriented and is implemented in a format that provides a "Title" metadata attribute which is exposed to assistive technology and is editable using the primary authoring tools for that document format, the non-web document has a title that describes the name, topic, or purpose.
Daniel: prefer to keep the "which is exposed to assistive technology" or determinable to be exposed to AT - to cover the future
GreggVan: Programmatically determinable is defined already
<loicmn> +1 to programmatically determinable
<GreggVan> Proposal 2.4.2 Non-web Document Titled: Where a non-web document is page-oriented and is implemented in a format that provides a programmatically determinable "Title" metadata attribute and is editable using the primary authoring tools for that document format, the non-web document has a title that describes the name, topic, or purpose.
<GreggVan> Proposal 2.4.2 Non-web Document Titled: Where a non-web document is page-oriented and is implemented in a format that provides a programmatically determinable "Title" metadata attribute and is editable using the primary authoring tools for that document format, the non-web document has a title that describes the name, topic, or purpose.
GreggVan: You need to be able to add the title in the primary tool - you shouldn't need to use an obscure metadata tool
… Maybe say in common authoring tools
Daniel: prefer to say common or usual
<maryjom> 2.4.2 Non-web Document Titled: Where a non-web document is page-oriented and is implemented in a format that provides a programmatically determinable "Title" metadata attribute and is editable using common authoring tools for that document format, the non-web document has a title that describes the name, topic, or purpose.
Latest proposal pasted above
Daniel: Still need a WCAG2ICT style - not the EN style that starts with the precondition.
Introductory paragraph has been updated
Proposal 3.
This success criterion is problematic to apply directly to non-web documents through simple word substitution because not all document formats provide support for a programmatically determinable ”Title” attribute, and document titles don't always describe the topic or purpose of the document. File names, as the WCAG 2 Understanding document
allows, also rarely describe the topic or purpose of the document – especially where the document names are not under the author’s control. However, where the document authoring tool or technology provides the capability to supply title metadata or name for a document, such as page-oriented publishing tools and word processing applications,
when the non-web document utilizes the “Title” attribute to provide a unique title or name inside of each document, and/or when a meaningful file name can be supplied, the user can more easily find it or understand its purpose. This would address the user needs identified in the Intent from Understanding Success Criterion 2.4.2. The following
criterion is recommended as a substitute for the WCAG language:
GreggVan: Would like to keep page oriented in there to avoid people having to name photos & other non-page oriented files
Daniel: Worried about the requirement for page oriented - workaround would be to make something pageless - then you would not need to meet the requirement
Daniel: Another option might be to give very specific examples instead of saying page oriented.
GreggVan: Could we say textual document instead of page oriented
Daniel: That excludes everything that is not textual
Daniel: Again suggested specific examples of things that should be excluded.
GreggVan: Agree that we change page oriented - and suggested textual documents as an alternative, or do we want to cover other types of document
<loicmn> +1 to remove "page oriented". Movie and image file formats may have metadata and when it happens then 2.4.2 applies
Mary Jo: We will meet tomorrow at the same time to try to resolve Page Titled.
Mike: We could potentially reapply this SC to non-web software using similar language to what is proposed for non-web documents.
Gregg: Yes, by adding "name" the name of the software would suffice.