On Mon, Jun 21, 2010 at 5:57 AM, Tisza Gergo wrote:
> Infoboxes would do fine, navboxes not so much. Consider something like [1],
> how
> would that work with fixed widths?
>
> If I remember correctly, there was an effort a while ago to make navbox markup
> less ugly (make it use a single table a
Marco Schuster harddisk.is-a-geek.org> writes:
> But why is IE8 falling back to compat-mode at Wikimedia sites?
Microsoft has a blacklist for sites they deem incompatible with IE8, and
Wikimedia sites are on that list (see [1]). No idea why, Wikipedia looks pretty
much the same in IE7 and (non-
Aryeh Gregor gmail.com> writes:
> I'm pretty sure that infoboxes can be done just fine with divs. Not
> exactly as they are now, but well enough. You can't get the exact
> auto-width algorithm for the cells, but in typical infoboxes it will
> be fine if you just set it to 50% or something. And
On Sat, Jun 19, 2010 at 9:59 AM, Dmitriy Sintsov wrote:
> Maybe it would be better to introduce non-standard (user-defined)
> attribute of element (tag), to indicate the type of table ("real table"
> or "layout table"), instead of breaking existing code? Then, screen
> readers could easily pick th
On Sun, Jun 20, 2010 at 2:12 PM, Tisza Gergo wrote:
> Anyway, removing table-related attributes doesn't offer much advantage in
> itself. There will be a few validator warnings about it, so what? Getting rid
> of
> table layouts would be nice, but IE6/7 do not understand display:table either,
> s
Marco Schuster harddisk.is-a-geek.org> writes:
> How big is the market share of such buggy browsers (and what are
> they)? I'd prefer progress and nice, clean code over having to keep
> old cruft just because some people still use middle-age browsers.
Amongst other things, IE6 and 7 do not under
On Sun, Jun 20, 2010 at 11:33 AM, Tisza Gergo wrote:
> Those all have CSS equivalents, so all it would achieve is to make
> presentational tables look uglier in older browsers where the CSS versions of
> those attributes are sometimes buggy.
How big is the market share of such buggy browsers (and
Aryeh Gregor gmail.com> writes:
> Oh, I see. That's really terrible, then, and we should avoid
> presentational tables if at all possible. I think this really has to
> be done on the content side, though, not on the software side --
> auto-translating tables to divs sounds like a bad idea.
IE
* Aryeh Gregor [Fri, 18 Jun 2010
15:40:54 -0400]:
> Oh, I see. That's really terrible, then, and we should avoid
> presentational tables if at all possible. I think this really has to
> be done on the content side, though, not on the software side --
> auto-translating tables to divs sound
On Fri, Jun 18, 2010 at 2:27 PM, Maria Schiewe
wrote:
> It’s not about the screen reader preventing the interaction. The interaction
> will be the same as for keyboard-only users. The problem is that there is no
> indication that the element can be interacted with. It is a heading level 5.
> Ho
Hello Aryeh,
Thank you for your answers and questions.
> The screen readers should allow the user to expand the menus just like
> sighted users can -- if that can't be done, that's what should be fixed.
It’s not about the screen reader preventing the interaction. The interaction
will be the sa
2010/6/18 Daniel Kinzler :
> 3) hidden (collapsed) menus use display:none. This makes them inaccessible to
> screen readers, etc. Alternative ways for hiding them might be better - such
> as
> setting the hight to 0. Has this been tried?
display: none seems completely appropriate here. The scree
Hello all,
I have a second suggestion for the alt problem that will require the use of
WAI-ARIA, namely aria-describedby. Drawback: That is currently only valid in
HTML 5. But it would be the better solution since alternative text and caption
text are two different things (see also
http://en.w
Hello Platonides,
> Those should have a title attribute.
On German Wikipedia I see no titleattribute if I specify a caption for an image.
> We used to have alt attribute equal to the title, but that was removed for
> duplicating it and being in fact ignored. Is some screen reader preferring
>
2010/6/18 Platonides :
> That looks like a bug. CollapsibleNav is using mousedown and keypress
> events instead of onclick.
>
We have been using mousedown instead of onclick to improve perceived
performance, IIRC. Replacing mousedown with onclick would eliminate
the need for hooking keypress AFAIK
Daniel Kinzler wrote:
> Hi all
>
> Today I got a review of Vector's accessibility from an employee of the German
> Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB). This
> is by no means a full evaluation, just the result of having a casual look. I
> visited them with Till
Hi all,
Many thanks to Sebastian from the DZB for his quick accessibility inspection.
I wanted to comment on two things.
> 3) hidden (collapsed) menus use display:none. This makes them inaccessible to
> screen readers, etc. Alternative ways for hiding them might be better - such
> as setting t
Hi all
Today I got a review of Vector's accessibility from an employee of the German
Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB). This
is by no means a full evaluation, just the result of having a casual look. I
visited them with Till and Maria of Wikimedia Germany a w
18 matches
Mail list logo
