E-mail List Archives
Thread: Tried to make it accessible; now it doesn't look good
Number of posts in this thread: 13 (In chronological order)
From: Haim Roman
Date: Sat, Oct 13 2018 12:12PM
Subject: Tried to make it accessible; now it doesn't look good
No previous message | Next message →
The site I'm working on has been using complex tables-within-tables for
layout. I'm trying to get rid of them to make the site more accessible.
NOTE: I used chrome on a PC.
1. One possibility is to use CSS "display:table*" to simulate table
layout without table semantics. Except that I read that s*ome screen
readers will interpret such CSS as actual tables*. Is this still true?
2. I'm working on the icons to change the language. They're currently
icons within BUTTON tags (type "submit") that are within a FORM tag. When
I try to position this form via CSS, I discovered that the icons occupy
only the *top half* of the form's box. The bottom half is empty. I
don't see any CSS causing that. This means I need extra CSS code to
vertically align the icons in the middle. Is this true, or am I missing
something?
3. I thought about implementing as A HREF links instead of a form (with
the desired language in the link). But I read that *there is no real
way to disable* an A HREF element. Is that true? There are hacks, but
I don't know how screen readers will interpret them.
Thanks
Howard (Haim) Roman -- = EMAIL ADDRESS REMOVED = -- 052-8-592-599 -- ×××× ×¨×××
LinkedIn: https://www.linkedin.com/in/haimroman
From: glen walker
Date: Sat, Oct 13 2018 12:50PM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
The easiest way to indicate a table is for layout is by setting the role to
presentation. I would strongly not recommend messing with the CSS display
property with tables. It quickly confuses things.
So you could have something like this:
<table role="presentation">
<tr>
<td>
<table role="presentation">
<tr>
<td>
Note that only the table element needs the role="presentation". The <tr>
and <td> elements don't need it. But if you have a nested table that is
also used for layout, the nested table needs its own role="presentation".
For your specific questions:
1. Yes, setting display:table on <div> tags can make the element be treated
as a table, but it's not consistent on all browser/AT combinations. It's
not a reliable way to make a table. If you can't use real table elements,
then you have to use the table roles (table, row, cell, colheader,
rowheader).
2. Sorry, can't help with CSS for icons. But a side question for your
language buttons is if the language you present to the user is in the
native language for that language. That is, if the user wants to change to
French, does your button say "French" or does it say "Français"? Hopefully
the latter, and if so, make sure you have lang="fr" set on the element so
that the screen reader can switch dialects/accents.
3. Yes, it's correct that the "disabled" attribute does not work for anchor
tags. To disable a link, you'd have to set tabindex="-1" so that the user
cannot tab to it, and set aria-disabled="true" so that the screen reader
tells the user about the state. You may want to visually style it
differently too. Whether you consider those "hacks" is up to you.
Glen
From: JP Jamous
Date: Sat, Oct 13 2018 5:15PM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
Glen,
I agree with all that you said except to tabindex="-1". JAWS in IE11 will set focus on it. Be careful of that one. I have witnessed many developers in my company that use it and it created lots of problems. They blamed it on JAWS, but once the -1 index was removed JAWS behaved as expected.
You are correct that keyboard only users won't be able to set focus on it, but not JAWS users.
I would prefer using disabled="disabled". It still works better than anything else I have witnessed.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Saturday, October 13, 2018 1:51 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Tried to make it accessible; now it doesn't look good
The easiest way to indicate a table is for layout is by setting the role to presentation. I would strongly not recommend messing with the CSS display property with tables. It quickly confuses things.
So you could have something like this:
<table role="presentation">
<tr>
<td>
<table role="presentation">
<tr>
<td>
Note that only the table element needs the role="presentation". The <tr> and <td> elements don't need it. But if you have a nested table that is also used for layout, the nested table needs its own role="presentation".
For your specific questions:
1. Yes, setting display:table on <div> tags can make the element be treated as a table, but it's not consistent on all browser/AT combinations. It's not a reliable way to make a table. If you can't use real table elements, then you have to use the table roles (table, row, cell, colheader, rowheader).
2. Sorry, can't help with CSS for icons. But a side question for your language buttons is if the language you present to the user is in the native language for that language. That is, if the user wants to change to French, does your button say "French" or does it say "Français"? Hopefully the latter, and if so, make sure you have lang="fr" set on the element so that the screen reader can switch dialects/accents.
3. Yes, it's correct that the "disabled" attribute does not work for anchor tags. To disable a link, you'd have to set tabindex="-1" so that the user cannot tab to it, and set aria-disabled="true" so that the screen reader tells the user about the state. You may want to visually style it differently too. Whether you consider those "hacks" is up to you.
Glen
From: JP Jamous
Date: Sat, Oct 13 2018 5:37PM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
See my notes below.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Haim Roman
Sent: Saturday, October 13, 2018 1:12 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Tried to make it accessible; now it doesn't look good
The site I'm working on has been using complex tables-within-tables for layout. I'm trying to get rid of them to make the site more accessible.
NOTE: I used chrome on a PC.
1. One possibility is to use CSS "display:table*" to simulate table
layout without table semantics. Except that I read that s*ome screen
readers will interpret such CSS as actual tables*. Is this still true?
Bad call. Stay away from that. Use data tables and make your life easier if you are presenting data. For layout purposes, you can use the divs, you mentioned, that will be fine. However, make sure that their layout in the DOM is sequential and not the way you intent to display it via CSS. For example, you want to show first name and last name in column 1 row 1 and row 2, when in column 2 row 1 you want to show date of birth and row 2 gender. Your markup in the DOM should be layed out as such.
<div>
First name
</div>
<div>
Last Name
</div>
<div>
<Date of Birth
</div>
<div>
Gender
</div>
This is what we call visual versus programmatic layout. So visually, you make it look like a table however screen readers, for the most part, are blind to what is included in CSS. They only read the DOM and based on its structure report that to users.
2. I'm working on the icons to change the language. They're currently
icons within BUTTON tags (type "submit") that are within a FORM tag. When
I try to position this form via CSS, I discovered that the icons occupy
only the *top half* of the form's box. The bottom half is empty. I
don't see any CSS causing that. This means I need extra CSS code to
vertically align the icons in the middle. Is this true, or am I missing
something?
Definitely, this is a CSS layout issue. It does not impact screen reader users, but you better be careful for low vision and color-blind users. You want your icons clear and adding text description along to the icon, it would help your users big time. For example, add the icon which includes a question mark and next to it have the word "help". Don't expect that all of your users will understand what the question mark means by itself.
Another way you can work around your CSS problem is by using <<img>> inside the <button> That will help you position things much better. Just make sure that the <img> has an alt attribute.
<<img> alt="Francais" dir="ltr" lang="fr" src="http://icon.png" />
3. I thought about implementing as A HREF links instead of a form (with
the desired language in the link). But I read that *there is no real
way to disable* an A HREF element. Is that true? There are hacks, but
I don't know how screen readers will interpret them.
You stated earlier that you were using buttons. If you are switching a language and not redirecting the user to a different URL, then you need to stick with buttons. Remember that buttons fire actions on the page, but links redirect the user to a different page or place on the page.
As Glen mentioned, make sure that your buttons use dir="ltr" or dir="rtl" along with lang="fr" for French or lang="ar" for Arabic.
I have witnessed many sites that use lang="ar" for Arabic but they do not set the dir="rtl". So the Arabic is written from left to right rather from right to left as it should be. That tends to confuse sighted and screen reader users, because the output becomes all screwed up. The same applies to Hebrew.
Thanks
Howard (Haim) Roman -- = EMAIL ADDRESS REMOVED = -- 052-8-592-599 -- ×××× ×¨×××
LinkedIn: https://www.linkedin.com/in/haimroman
From: glen walker
Date: Sat, Oct 13 2018 5:47PM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
JP, yes, sorry I forgot to include that.
In addition to tabindex="-1", you either need to aria hide it or override
the keyboard handler to not let a selection navigate the link.
Setting aria-hidden="true" is the easy way to hide it so that JAWS will not
get to it. But if you still want it in the accessibility tree, and have it
announced disabled/inactive (aria-disabled="true"), then you'd need a
keyboard handler to filter out the events.
You can't set disabled="disabled" on a link because it's not valid html.
From: Private Loader
Date: Sat, Oct 13 2018 5:58PM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
Sorry no calcs here
De: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > em nome de glen walker < = EMAIL ADDRESS REMOVED = >
Enviado: 14 de outubro de 2018 00:47
Para: WebAIM Discussion List
Assunto: Re: [WebAIM] Tried to make it accessible; now it doesn't look good
JP, yes, sorry I forgot to include that.
In addition to tabindex="-1", you either need to aria hide it or override
the keyboard handler to not let a selection navigate the link.
Setting aria-hidden="true" is the easy way to hide it so that JAWS will not
get to it. But if you still want it in the accessibility tree, and have it
announced disabled/inactive (aria-disabled="true"), then you'd need a
keyboard handler to filter out the events.
You can't set disabled="disabled" on a link because it's not valid html.
From: Haim Roman
Date: Sun, Oct 14 2018 1:06AM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
First, I thank very much everyone who answered me. I'll be considering all
of the answers.
Regarding the presentation role: MDN's page on this role (
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_presentation_role)
says:
Opinions may differ on how assistive technology should handle this
technique. The information provided above is one of those opinions and
therefore not normative.
It sounds like you can't count on this role making all screen readers
ignore the fact that this is a table.
The opinion referred to is:
The presentation role is used to remove semantic meaning from an element
and any of its related child elements. For example, a table used for layout
purposes could have the presentation role applied to the table element to
remove any semantic meaning from the table element and any of its table
related children elements, such as table headers and table data elements.
Howard (Haim) Roman -- = EMAIL ADDRESS REMOVED = -- 052-8-592-599 -- ×××× ×¨×××
LinkedIn: https://www.linkedin.com/in/haimroman
On Sat, Oct 13, 2018 at 9:50 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> The easiest way to indicate a table is for layout is by setting the role to
> presentation. I would strongly not recommend messing with the CSS display
> property with tables. It quickly confuses things.
>
> So you could have something like this:
>
> <table role="presentation">
> <tr>
> <td>
> <table role="presentation">
> <tr>
> <td>
>
> Note that only the table element needs the role="presentation". The <tr>
> and <td> elements don't need it. But if you have a nested table that is
> also used for layout, the nested table needs its own role="presentation".
>
> For your specific questions:
> 1. Yes, setting display:table on <div> tags can make the element be treated
> as a table, but it's not consistent on all browser/AT combinations. It's
> not a reliable way to make a table. If you can't use real table elements,
> then you have to use the table roles (table, row, cell, colheader,
> rowheader).
> 2. Sorry, can't help with CSS for icons. But a side question for your
> language buttons is if the language you present to the user is in the
> native language for that language. That is, if the user wants to change to
> French, does your button say "French" or does it say "Français"? Hopefully
> the latter, and if so, make sure you have lang="fr" set on the element so
> that the screen reader can switch dialects/accents.
> 3. Yes, it's correct that the "disabled" attribute does not work for anchor
> tags. To disable a link, you'd have to set tabindex="-1" so that the user
> cannot tab to it, and set aria-disabled="true" so that the screen reader
> tells the user about the state. You may want to visually style it
> differently too. Whether you consider those "hacks" is up to you.
>
> Glen
> > > > >
From: glen walker
Date: Sun, Oct 14 2018 1:06AM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
role="presentation" on a table is well supported in all browsers/screen
readers
From: Mark Rogers
Date: Sun, Oct 14 2018 4:13AM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
Check if the document is rendering in Quirks mode - this happens if it has no DOCTYPE, a malformed DOCTYPE or uses certain old DOCTYPEs:
https://html.spec.whatwg.org/multipage/parsing.html#the-initial-insertion-mode
In quirks mode a 1em margin is added to the bottom of the form:
https://html.spec.whatwg.org/multipage/rendering.html#flow-content-3
2. I'm working on the icons to change the language. They're currently
icons within BUTTON tags (type "submit") that are within a FORM tag. When
I try to position this form via CSS, I discovered that the icons occupy
only the *top half* of the form's box. The bottom half is empty. I
don't see any CSS causing that. This means I need extra CSS code to
vertically align the icons in the middle. Is this true, or am I missing
something?
Best Regards
Mark
--
Mark Rogers - = EMAIL ADDRESS REMOVED =
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
From: JP Jamous
Date: Sun, Oct 14 2018 8:02AM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
Ah got your point now Glen. I misunderstood you pal.
I find the disabled="disabled" attribute to be interesting. Many folks refer
to it as deprecated or not semantically correct, yet it does work in all
browsers and ATs that I have tested.
I do agree with you Glen that if you want to disable a link, why include it
in the first place on the page. Set display: none; and when you want it to
appear set display: inline; That way both sighted and AT users benefit from
it.
In my humble opinion, having it there in the tab order disabled is extra
navigation overhead for screen reader users and keyboard only users.
Anyways, I am a big fan of Keep It Simple. The simpler the layout is, the
better the user experience. That is a part of inclusive design in a way,
where the UI works to the benefit of all users not just one type of users.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen
walker
Sent: Saturday, October 13, 2018 6:48 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Tried to make it accessible; now it doesn't look good
JP, yes, sorry I forgot to include that.
In addition to tabindex="-1", you either need to aria hide it or override
the keyboard handler to not let a selection navigate the link.
Setting aria-hidden="true" is the easy way to hide it so that JAWS will not
get to it. But if you still want it in the accessibility tree, and have it
announced disabled/inactive (aria-disabled="true"), then you'd need a
keyboard handler to filter out the events.
You can't set disabled="disabled" on a link because it's not valid html.
http://webaim.org/discussion/archives
From: Patrick H. Lauke
Date: Sun, Oct 14 2018 9:12AM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
On 14/10/2018 15:02, JP Jamous wrote:
> I find the disabled="disabled" attribute to be interesting. Many folks refer
> to it as deprecated or not semantically correct, yet it does work in all
> browsers and ATs that I have tested.
A link with the disabled attribute still gets focus and can be activated
as normal in Firefox, Chrome, Edge using NVDA, JAWS and Narrator. The
only browser where I've seen links with disabled="disabled" acting as
actually disabled links is IE11 (and there the behavior is non-standard,
as disabled is not a valid attribute for links).
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: glen walker
Date: Sun, Oct 14 2018 12:43PM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | Next message →
I tend to shy away from html that is not compliant. Even if disabled
worked on a link, it is not valid html and will fail the
https://validator.w3.org/nu validator, and thus fail WCAG 4.1.1 (maybe).
I say "maybe" fail 4.1.1 because if you go by the letter of the law, 4.1.1
doesn't say anything about invalid attributes, just about opening and
closing tags, duplicate IDs, or duplicate attributes.
On Sun, Oct 14, 2018 at 9:12 AM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:
> On 14/10/2018 15:02, JP Jamous wrote:
>
> > I find the disabled="disabled" attribute to be interesting. Many folks
> refer
> > to it as deprecated or not semantically correct, yet it does work in all
> > browsers and ATs that I have tested.
>
> A link with the disabled attribute still gets focus and can be activated
> as normal in Firefox, Chrome, Edge using NVDA, JAWS and Narrator. The
> only browser where I've seen links with disabled="disabled" acting as
> actually disabled links is IE11 (and there the behavior is non-standard,
> as disabled is not a valid attribute for links).
>
> P
> --
> Patrick H. Lauke
>
From: Isabel Holdsworth
Date: Mon, Oct 15 2018 3:27AM
Subject: Re: Tried to make it accessible; now it doesn't look good
← Previous message | No next message
Hi Haim,
Layout tables are not inherently inaccessible. So long as
screenreaders and other AT are made aware of which tables are for data
and which are for layout purposes, things work just fine. Purely
personal opinion here, but as a developer I'd rather debug a layout
table than a deeply nested set of DIVs. If you make sure that all
layout tables have a role of "presentation" and all data tables don't
have a "role" attribute set (the accessibility tree will derive their
role from the <table> tag), this shouldn't present any accessibility
barriers.
As has been said before, buttons should be used for changing the
language of a page, each with its own "lang" and "dir" attributes.
Even if the text direction of a button is the same as the current page
language, it should be set so it's displayed correctly in every
language.
Cheers.
On 14/10/2018, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> I tend to shy away from html that is not compliant. Even if disabled
> worked on a link, it is not valid html and will fail the
> https://validator.w3.org/nu validator, and thus fail WCAG 4.1.1 (maybe).
>
> I say "maybe" fail 4.1.1 because if you go by the letter of the law, 4.1.1
> doesn't say anything about invalid attributes, just about opening and
> closing tags, duplicate IDs, or duplicate attributes.
>
> On Sun, Oct 14, 2018 at 9:12 AM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> On 14/10/2018 15:02, JP Jamous wrote:
>>
>> > I find the disabled="disabled" attribute to be interesting. Many folks
>> refer
>> > to it as deprecated or not semantically correct, yet it does work in
>> > all
>> > browsers and ATs that I have tested.
>>
>> A link with the disabled attribute still gets focus and can be activated
>> as normal in Firefox, Chrome, Edge using NVDA, JAWS and Narrator. The
>> only browser where I've seen links with disabled="disabled" acting as
>> actually disabled links is IE11 (and there the behavior is non-standard,
>> as disabled is not a valid attribute for links).
>>
>> P
>> --
>> Patrick H. Lauke
>>
> > > > >