highlighting an accesskey

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • Lea GRIS
    #1

    highlighting an accesskey

    Hello,

    Are there any generic and CSS standard mean of highlighting an accesskey?

    I only fond a workaround by encapsulating the corresponding letter in a
    <em></eminside the label. But it is not applicable for a submit button
    which label is not a content.

    Here is en example:
    <form method="get" action="http://example.com/cgi-bin/smokeping.cgi"
    enctype="multip art/form-data" id="rangeform" >
    <fieldset><lege nd>Time range:</legend>
    <label for="start"><em >F</em>rom:</label>
    <input type="text" name="start" tabindex="1" value="2008-04-16
    11:22" accesskey="f" id="start" />
    <label for="end"><em>T </em>o:</label>
    <input type="text" name="end" tabindex="2" value="now"
    accesskey="t" id="end" />
    <input type="hidden" name="target" value="World.Eu rope.France.IPv 6" />
    <input type="hidden" name="displaymo de" value="n" />
    <input type="submit" tabindex="3" name="Generate! "
    value="Generate !" accesskey="g" />
    </fieldset>
    </form>

    There would also exist another unsatisfying possibility with CSS:

    input:before { content: attr(accesskey) ; }

    But it would display the accesskey outside the label and before or after
    the input field. Furthermore, there are few compatible browsers.

    Regards,

    --
    Léa Gris
    Tags: None
    • Sander Tekelenburg
      #2
      Re: highlighting an accesskey

      In article <tFtNj.327194$b c6.139693@reade r1.news.saunala hti.fi>,
      "Jukka K. Korpela" <jkorpela@cs.tu t.fiwrote:

      [...]
      The HTML side of the matter is that accesskeys, as defined in HTML, are
      mostly useless or worse than useless, partly because they may interfere
      with browser or system accesskey assignments that users are familiar
      with and may really need.
      In my book letting a site hi-jack browser functionality would count as a
      browser bug. In that same book browser bugs should be repaired by
      browser vendors, not by web publishers. The more web publishers use
      accesskey, the more users afected, the more likely browser vendors will
      bother to fix the bug. Thus this could be considered an argument for
      using accesskey...

      IMO a more valid argument against acceskey is that it's a per site
      solution for something that ought to have a cross site solution. (Yep,
      browser vendors again ;))

      --
      Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>

        Comment

        • Harlan Messinger
          #3
          Re: highlighting an accesskey

          Sander Tekelenburg wrote:
          In article <tFtNj.327194$b c6.139693@reade r1.news.saunala hti.fi>,
          "Jukka K. Korpela" <jkorpela@cs.tu t.fiwrote:
          >
          [...]
          >
          >The HTML side of the matter is that accesskeys, as defined in HTML,
          >are mostly useless or worse than useless, partly because they may
          >interfere with browser or system accesskey assignments that users
          >are familiar with and may really need.
          >
          In my book letting a site hi-jack browser functionality would count
          as a browser bug.
          It's a feature provided by the HTML standard, so whatever you may think
          of it, it isn't a bug for a browser to implement it.
          IMO a more valid argument against acceskey is that it's a per site
          solution for something that ought to have a cross site solution.
          (Yep, browser vendors again ;))
          How can you have a cross-site solution for something that is inherently
          site-specific? That isn't the problem with access keys, any more than
          it's a problem that the same Ctrl key combination will serve different
          purposes in different OS windows.

            Comment

            • Jukka K. Korpela
              #4
              Re: highlighting an accesskey

              Scripsit Sander Tekelenburg:
              In my book letting a site hi-jack browser functionality would count
              as a browser bug.
              Well, maybe, and browsers _could_ actually implement accesskeys in a
              manner that does not do that, but they don't. The HTML specification is
              naive in its assumptions, pretending that browsers could recognize Alt+F
              as a shortcut for a page-defined accesskey, as if Alt+F were not bound
              to some function in most situations (and that users could use
              page-defined accesskeys and would want to do that).
              In that same book browser bugs should be repaired by
              browser vendors, not by web publishers.
              The fundamental flaw is in the specifications. The best browsers could
              do now is to stop recognizing accesskey attributes at all.
              The more web publishers use
              accesskey, the more users afected, the more likely browser vendors
              will bother to fix the bug.
              You seem to advocate a catastrophe theory. According to it, should we
              start pushing vendors into implementing at least HTML 2.0? That is,
              should we use all the SGML features defined in specifications HTML 2.0
              through HTML 4.01, like <title/foo/ for a title element? Or should we be
              modern and use native XHTML, _without_ dirty Appendix C trickery, and
              naturally sending application/xhtml+xml to everyone?

              --
              Jukka K. Korpela ("Yucca")
              http://www.cs.tut.fi/~jkorpela/


                Comment

                • Lea GRIS
                  #5
                  Re: highlighting an accesskey

                  Jukka K. Korpela a écrit :
                  Scripsit Sander Tekelenburg:
                  >
                  >In my book letting a site hi-jack browser functionality would count
                  >as a browser bug.
                  >
                  Well, maybe, and browsers _could_ actually implement accesskeys in a
                  manner that does not do that, but they don't. The HTML specification is
                  naive in its assumptions, pretending that browsers could recognize Alt+F
                  as a shortcut for a page-defined accesskey, as if Alt+F were not bound
                  to some function in most situations (and that users could use
                  page-defined accesskeys and would want to do that).
                  IMHO: The most able browser in handling accesskey is Opera (Taype ESC
                  key then it display all shortcuts and corresponding accesskey to hit).

                  Firefox is quite inconsistant across versions. Prior to vrsion 2 it used
                  ALT+accesskey, wich could conflict with system shortcuts. Since version
                  2, it handle it by SHIFT+ALT+acces skey, ahthough it is user settalble, I
                  like much the Opra way of handling it.

                  To go back about highlighting the shortcuts, I managed to do it that way :

                  <http://meumeu/cgi-bin/smokeping.cgi?d isplaymode=n;st art=2008-04-19%2012:05;end= now;target=Worl d.Europe.France .Free>

                  Regards,

                  --
                  Léa Gris

                    Comment

                    • Sander Tekelenburg
                      #6
                      Re: highlighting an accesskey

                      In article <XYZNj.327824$y c7.91790@reader 1.news.saunalah ti.fi>,
                      "Jukka K. Korpela" <jkorpela@cs.tu t.fiwrote:
                      Scripsit Sander Tekelenburg:
                      >
                      In my book letting a site hi-jack browser functionality would count
                      as a browser bug.
                      >
                      Well, maybe, and browsers _could_ actually implement accesskeys in a
                      manner that does not do that, but they don't.
                      iCab provided non-hijackable accesskey support about 10 years ago
                      already. I thought Opera does too, since about 5.0 or 6.0, by providing
                      a mode change. Modes aren't exactly for everyone, but at least this
                      shows that an impementation that keeps the user in control is possible.
                      The HTML specification is naive in its assumptions
                      Agreed. It doesn't say UAs are required to implement that naively though.

                      [...]
                      The fundamental flaw is in the specifications. The best browsers could
                      do now is to stop recognizing accesskey attributes at all.
                      Depends on the implementation. Why should ones that don't generate
                      problems disappear?

                      Mind you, in my opinion providing keyboard accessibility isn't something
                      web publishers should be burdened with in the first place. The spec's
                      "Authors should consider the input method of the expected reader when
                      specifying an accesskey" is probably the worst bit it has to say on
                      accesskey -- authors should not target a specific browsing environment.
                      The more web publishers use
                      accesskey, the more users afected, the more likely browser vendors
                      will bother to fix the bug.
                      >
                      You seem to advocate a catastrophe theory.
                      {shrug} I'm just being realistic. Web publishers cannot predict in which
                      browsing environment their documents will be consumed and therefore
                      *cannot* solve these sorts of problems.

                      I believe that the only way the Web will ever become a realiable tool is
                      when [1] users demand better UAs and [2] authors demand better authoring
                      tools. (I'm trying to help improve the situation regarding the latter:
                      <http://webrepair.org/>.) Users will only demand better UAs when they
                      are confronted with obvious problems. Therefore, authors hiding those
                      problems from users does nothing to improve the situation.
                      According to it, should we
                      start pushing vendors into implementing at least HTML 2.0?
                      I wouldn't mind seeing usable cross browser support for @rel. (See
                      <http://www.euronet.nl/~tekelenb/WWW/LINK/>.)

                      --
                      Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>

                        Comment

                        Previous template Next
                        Working...