====== Issues For and Questions About the a11yspec Template ====== =====Contents===== * [[https://www.linuxfoundation.org/#Issues_For_and_Questions_About_the_a11yspec_Template|1 Issues For and Questions About the a11yspec Template]] * [[https://www.linuxfoundation.org/#General_Issues_Which_Need_to_Be_Addressed_for_All_Specifications|1.1 General Issues Which Need to Be Addressed for All Specifications]] * [[https://www.linuxfoundation.org/#General_Issues_Which_Have_Been_Answered|1.1.1 General Issues Which Have Been Answered]] * [[https://www.linuxfoundation.org/#KAFS-specific_Issues|1.1.2 KAFS-specific Issues]] * [[https://www.linuxfoundation.org/#Specific_MarkUp_Issues|1.2 Specific MarkUp Issues]] * [[https://www.linuxfoundation.org/#Syntaxic_Conventions_for_Open_A11y_Specifications|1.3 Syntaxic Conventions for Open A11y Specifications]] \\ ===== General Issues Which Need to Be Addressed for All Specifications===== - boilerplate "copyright" and "licensing" verbiage -- get from from LF? * **status: //to be resolved 29 January 2008//** Does the //[[http://creativecommons.org/license/results-one?q_1=2&q_1=1&field_commercial=yes&field_derivatives=sa&field_jurisdiction=us&field_format=&field_worktitle=&field_attribute_to_name=&field_attribute_to_url=&field_sourceurl=&field_morepermissionsurl=&lang=en_US&language=en_US&n_questions=3|Creative Commons License]]//, suggested by Dan Kohn, sufficient? * **if issuing software or libraries, use:** //[[http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt|GNU General Public License, Version 2]]// - is there a boilerplate LF template? * **//no//** - should the boilerplate template be Open A11y specific? * //status:// yes, to the greatest extent possible - we obviously want to use the [[http://accessibility.linux-foundation.org/a11yweb/images/longdesc/OpenA11y.html|Open A11y logo]] -- what about the LF logo? is it required? * //status:// use of the LF is not, required but appreciated - is verbiage needed re: trademarks of companies, interested parties, implementors? * //status:// no boilerplate text available from LF - need boilerplate "status of this document" declarations * //status:// under consideration - is any [[https://www.linuxfoundation.org/Accessibility/Kbd/Specs/Template/Issues/Wrappers|other boilerplate material]] needed? * //status:// under consideration \\ ==== General Issues Which Have Been Answered ==== * the feedback address for **all** Open A11y specifications will be [[https://lists.linux-foundation.org/mailman/listinfo/accessibility-rfc|accessibility-rfc@lists.linux-foundation.org]] * the feedback address will be included in each specification's Introduction (after verbiage such as "this specification was developed by the LF/Open A11y Keyboard Committee/Subgroup/SIG. To provide feedback, report errors or inquiries, please send email to [[https://lists.linux-foundation.org/mailman/listinfo/accessibility-rfc|accessibility-rfc@a11y.org]]" **and** in the ''ADDRESS'' section of the specification. \\ ==== KAFS-specific Issues==== - in the auto-generated version of the spec, 'class' is used extensively as a pseudo-semantic attribute -- that practice can be continued, but it is best if the anchors have some meaning in and of themselves rather than an alphanumeric code, as is currently the case. the other options is to use [[http://www.w3.org/TR/2007/WD-rdfa-syntax-20071018/|RDFa]] or simply use the ''id/name'' binding? i have removed the "emphasis" class from the ''I'' elements and converted them to ''EM'' tags to which specific styling can be applied; for example the ''I'' element was used to demarcate concepts such as StickyKeys, BounceKeys, etc. was classed as "emphasis" -- this should be classed as "spec-term" or "concept" or something similar\\ \\ - we want to (at least) use dublin core markup in the ''HEAD'' via the meta element, right? (note that empty content fields are those i felt better populated by the editors) we still need to locate the current home (if any) of the XBE document referenced in the specification (and our CSUN 2008 proposal) -- i extensively searched all of the ftp.x.org mirrors, but could not find:\\ \\ [[http://ftp.x.org/pub/R6.4/xc/doc/specs/XKB/XKBlib/allchaps.ps|http://ftp.x.org/pub/R6.4/xc/doc/specs/XKB/XKBlib/allchaps.ps]]\\ [[http://web.archive.org/web/20020528232134/ftp.x.org/pub/R6.4/xc/doc/specs/XKB/XKBlib/|http://web.archive.org/web/20020528232134/ftp.x.org/pub/R6.4/xc/doc/specs/XKB/XKBlib/]] when last this issue was discussed, the closest thing GJR had found to a "stable" reference was an 18 November 1997 date-stamped WayBackMachine archived copy of the original directory, complete with both: allchaps.ps and allchaps.pdf which can be found at:\\ \\ [[http://web.archive.org/web/20020528232134/http://ftp.x.org/pub/R6.4/xc/doc/specs/XKB/XKBlib/allchaps.ps|http://web.archive.org/web/20020528232134/http://ftp.x.org/pub/R6.4/xc/doc/specs/XKB/XKBlib/allchaps.ps]] \\ ---- ===== Specific MarkUp Issues===== * the document-type of Open A11y specifications will be [[http://www.w3.org/TR/xhtml10/|XHTML 1.0 Strict]] * **all** tables used in a specification **must** contain (at least): a ''summary'', ''headers/id'' bindings, ''scope'' and a ''CAPTION''; styling of tables should be handled with CSS, rather than be hard-coded into the ''TABLE'' * expansions **must** be provided for all acronyms and abbreviations * all Open A11y specifications '''must''' contain an ''ADDRESS'' element, containing: contact information, means of providing feedback, reporting errors, etc.. The ''ADDRESS'' will also contain boilerplate Open A11y/Linux Foundation verbiage as far as copyright and permissions are concerned, as is common at the bottom of technical specs * **all** Open A11y specifications need a normative references section. For example, to document RFC2119 in the text, the string RFC2119 should point to an entry in the //Normative References// section. This will assist in the stability, longevity and maintenance of the document, as the links contained in the text will not be broken when a resource moves or a URI changes, but can document when the resource was accessed and make it easier to universally effect a change to a single URI through an accompanying errata document. (//a note on the example:// this is supposed to be an example of code contained in a ''DL'', but since the wiki allows certain HTML/XHTML markup without using ''HTML'' containers normally used to insert straight markup into a wiki page, and i have yet to be able to get the markup example to be rendered correctly) * **[RFC2119]** * //Key words for use in RFCs to indicate requirement levels//,[[http://www.ietf.org/rfc/rfc2119.txt|RFC 2119]], S. Bradner, March 1997.\\ Available at: [[http://www.rfc-editor.org/rfc/rfc2119.txt|http://www.rfc-editor.org/rfc/rfc2119.txt]] * a unified "look-and-feel" (as well as sounds for aural styling, which can be added later without affecting the spec) needs to be established * it is //**strongly**// recommended that CSS be used for controlling the printed version of the spec when printed from the XHTML document? \\ ---- ===== Syntaxic Conventions for Open A11y Specifications===== * all Open A11y specifications will conforms to [[http://www.rfc-editor.org/rfc/rfc2119.txt|RFC2119]] to specify declarative, normative keywords, for example:\\ * "The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]." * **all** anchor values **must** be lower-case * any anchor ''name''/''id'' **must** be human-parseable * when a term is defined, the anchor to that definition should take the form ''def-foo'', where ''foo'' is the concept's name; for example, ''def-mousekeys'' \\ ---- * [[:accessibility:kbd:specs:template:issues:wrappers|Wrappers for the Keyboard Access Functional Specification]] * [[:accessibility:kbd:start|Keyboard Committee's main page]] * [[:accessibility:specs:start|Open Accessibility Draft Specifications Guidelines & Index]] * [[:accessibility:start|Open Accessibility main page]]