This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
use < and > and not ← and → to indicate previous and next in the top-level menu that appears at the beginning of the sections of http://dev.w3.org/html5/spec/ the character-entity used to indicate "previous" is ← whilst the character-entity used to indicate "next" is → as follows: <a href="editing.html">← 7 User interaction</a> – <a href="spec.html#contents">Table of contents</a> – <a href="syntax.html">8 The HTML syntax →</a> PROBLEM: most users will not be able to generate either → or ← from the keyboard, making it difficult to use these links when one invokes a list of links traversable by first character in hypertext SOLUTION: 1. replace ← with < (U+0003C) to indicate previous; 2. replace → with > (U+0003E) to indicate next; 3. gloss the symbolic (ascii art) indicators with ABBR as follows: <abbr title="previous"><</abbr> <abbr title="next">></abbr>
The Bug Triage Sub Team have reviewed this Bug and feel it is not a priority. The Bug can be advanced if Gregory decides that it is warranted.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Angle brackets aren't the appropriate Unicode characters here, so I'm WONTFIXing this. If there are ATs that don't handle Unicode correctly, they should be fixed.
(In reply to comment #2) > Status: Rejected > Change Description: no spec change > Rationale: Angle brackets aren't the appropriate Unicode characters here, so > I'm WONTFIXing this. If there are ATs that don't handle Unicode correctly, they > should be fixed. ian, i think you misunderstand the issue -- the problem isn't in the exposition of the unicode characters, but in their replication by a user who is trying to use a list of links or an auto-complete feature to get to/activate the link that leads to the previous and next sections -- i have a 101 key keyboard, and i don't know how to generate the character you are currently using as part of the hyperlink text in the navigational portion of the multi-page view; i can't even imagine how i would invoke it on a device with only a telephone keypad to input text or a braille keyboard (as one can do with the icon or braille plus from APH (american printing house for the blind - http://tech.aph.org/pda_doc.htm)
Realistically, it's not a problem. The "previous" link is the second link on the page, so just hitting tab twice will get you there if you went too far while traversing the spec forwards page by page. I don't really know why else you would click that link. The forwards link doesn't have the arrow at the start, so I don't see why you'd ever try to hit that one. Having said that, if people really do want to navigate the site that way, we could add accesskey="" attributes on the links with "<" and ">" as the values. Would that help?
(In reply to comment #4) hixie, thanks for your response -- QUOTE Having said that, if people really do want to navigate the site that way, we could add accesskey="" attributes on the links with "<" and ">" as the values. Would that help? UNQUOTE i think that adding < and > as accesskey values for the previous and next is a good idea, as long as there is some documentation somewhere that details the conventions used in the spec: * the keys "<" and ">" have been assigned as access keys for "previous" and "next" respectively personally, i would like to see a "Formatting Conventions Used in this Document" section added to the W3C boilerplate intro, so that spec authors can document for spec readers what precisely the formatting conventions used in the spec are, including a list of global accesskeys one serious problem with large web pages and assistive technologies is focus maintenance, which is why someone deep in the document might want to invoke a list of links with which to go to the previous or next section -- having "<" and ">" assigned as accesskeys WILL help, but the user should be able to generate the first character used as hyyperlink text without invoking a macro/special key-combo to generate the "special character" your point about the ">" character in a list of links is well-taken -- no one would need to generate the last character in hyperlink text in order to use it one last point of consideration -- how broad is the support for non-alpha-numeric characters when used as accesskeys? i have an old UAAG 1.0 proposed test page to test support for non-alpha-numeric characters used as accesskeys: http://www.hicom.net/~oedipus/wai/ua/tests/non-alpha-numeric_accesskey_test1.html
Bug triage sub-team reviewed, this is not an issue with the features of HTML so is not a HTML A11Y task force priority. However, we do agree there is an accessibility issue with the spec. It seems this could be solved by putting the arrows in via CSS so they are visible but not part of the link text, which is what is causing the accessibility problem. Using the "previous section" link as an example, it could be given a class of "prev" and the following CSS should work: a.prev:before {content: "← "}. The same could be done with the "next section link, e.g., a.next:after {content: " →"}.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: I updated the spec splitter such that arrows in the next/previous links are now generated using CSS, as described in comment 6. Rationale: The solution Michael Cooper proposed in comment 6 seems to be the best way to address the original request from Gregory. http://dev.w3.org/cvsweb/html5/spec/tools/spec-splitter.py.diff?r1=1.7&r2=1.8&f=h
Gregory, if you want access keys to be added to the next/previous links, please open a different bug for that, and indicate there what characters should be used ("<" and ">" don't seem like the best choices...)