E-mail List Archives
Thread: Available title indication via css
Number of posts in this thread: 14 (In chronological order)
From: Wolfgang Berndorfer
Date: Fri, Nov 10 2017 1:08PM
Subject: Available title indication via css
No previous message | Next message →
Hi!
Digging around in the main.css of webaim.org I was surprised that the visual
indication for the attribute [title] is only applied onABBR and DFN
elements.
Is there any reason not to use it generally for elements (*[title])?
If NO, could the following code be recommended as best practise:
*[title] {
border-bottom:1px dotted;
cursor:help;
}
It would support the recognability of the feature.
If there were aesthetic reasons against it, FAQ in the navigation would be
infected with abbr[title] anyway.
Hope, me Austian was understandable, who needs more often a TITLE in a
LANG-Attribute.
Wolfgang Berndorfer
From: Jared Smith
Date: Fri, Nov 10 2017 1:33PM
Subject: Re: Available title indication via css
← Previous message | Next message →
The title attribute value is not always read by screen readers (this
depends on the screen reader and the settings), is inaccessible to keyboard
users, is often not available to touch screen users, etc. So we rarely
recommend it and rarely use it on the WebAIM site.
And we rarely use or recommend <abbr> and <acronym>. Instead, commonly
known acronyms should be used, or they should be expanded in text in their
first instance.
Those styles are in place simply to present a more consistent visual
identification across browsers. Every browser tends to style <abbr> and
<acronym> differently. And some, including Safari, don't style them at all.
And even when styled, I suspect it's possible that users may confuse the
dotted or dashed underline for a link, except that you can't tab to it and
clicking it doesn't trigger a page change.
In short, the title attribute is generally problematic, unless used purely
for advisory information for mouse users and (sometimes) screen reader
users.
Thanks,
Jared Smith
WebAIM.org
From: Wolfgang Berndorfer
Date: Fri, Nov 10 2017 2:46PM
Subject: Re: Available title indication via css
← Previous message | Next message →
Hi Jared!
I totally agree that the TITLE attribute is somehow a Zombie in HTML:
1. Missing Keyboard and Touch Screen Accessibility in lot of cases.
2. Screen Reader Output depending on the available Screen Reader and
Settings.
3. Ambivalent infos in specs, techs and discussions.
4. Abusing, missunderstood and verbous usage.
But the Zombie is not dead but alive, practised and even often helpful.
ItÂs potentially helpful for sighted keyboard and mouse users, who siply
want to get some quick information. And those must visually get aware that
THERE WAS some advirsory information available.
So we could discusse a lot about the TITLE-attribute itself. But my question
was about HOW TO MAKE THE BEST OUT OF IT VIA STYLESHEETS.
If there was a standard for links to be underlined for additional or
descriptive informations to be dotted or dashed, somewhen there would be no
more missunderstandig. My impression is that there is already a tendency in
this direction.
And if Safari doesnÂt support this feature at all, I wold say: It should!
Good Night from Innsbruck!
Wolfgang
= EMAIL ADDRESS REMOVED =
http://www.zweiterblick.at
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
von Jared Smith
Gesendet: Freitag, 10. November 2017 21:34
An: WebAIM Discussion List
Betreff: Re: [WebAIM] Available title indication via css
The title attribute value is not always read by screen readers (this
depends on the screen reader and the settings), is inaccessible to keyboard
users, is often not available to touch screen users, etc. So we rarely
recommend it and rarely use it on the WebAIM site.
And we rarely use or recommend <abbr> and <acronym>. Instead, commonly
known acronyms should be used, or they should be expanded in text in their
first instance.
Those styles are in place simply to present a more consistent visual
identification across browsers. Every browser tends to style <abbr> and
<acronym> differently. And some, including Safari, don't style them at all.
And even when styled, I suspect it's possible that users may confuse the
dotted or dashed underline for a link, except that you can't tab to it and
clicking it doesn't trigger a page change.
In short, the title attribute is generally problematic, unless used purely
for advisory information for mouse users and (sometimes) screen reader
users.
Thanks,
Jared Smith
WebAIM.org
From: Bim Egan
Date: Fri, Nov 10 2017 11:38PM
Subject: Re: Available title indication via css
← Previous message | Next message →
Hi wolfgang,
Perhaps I'm just not getting the point here. Which group of people with
disabilities could benefit when styling is applied to the title attribute on
links (and other visible components)?
I imagine it could be useful for content editors as a visual prompt for
action. This could help avoid the danger of outdated title values when a
link's text and destination have changed. But that shouldn't be necessary.
Of course any one of the content editors might be disabled too. But even
here the benefit is slight if they can't use or see a mouse. . I can't
think of another accessibility use case though, can you?
Kind regards,
Bim
From: Wolfgang Berndorfer
Date: Sat, Nov 11 2017 3:26AM
Subject: Re: Available title indication via css
← Previous message | Next message →
Hi Bim,
DonÂt only think of people with disabilities. Imagine, You find an
abbreviation on a website, You donÂt understand: If the abbreviation is
visually perceivable as titled, You will hover with your mouse and get the
meaning of the abbreviation as a browser functionality. If the
TITLE-attribute wasnÂt styled, You would probably not try to hover to get
information. The titled abbreviation just looks like any other textelement.
Styling would help You, if You are sighted and can use the mouse. Even if
You need a magnification software, You benefit of the visual indication.
If You need a screen reader, the information You get, depends on Your
settings and not on the styling. But this is an other issue.
<span lang="de" title="best regards">Beste GrüÃe!</span>
Wolfgang
From: Patrick H. Lauke
Date: Sat, Nov 11 2017 5:43AM
Subject: Re: Available title indication via css
← Previous message | Next message →
On 11/11/2017 10:26, Wolfgang Berndorfer wrote:
> Hi Bim,
> DonÂt only think of people with disabilities. Imagine, You find an
> abbreviation on a website, You donÂt understand: If the abbreviation is
> visually perceivable as titled, You will hover with your mouse and get the
> meaning of the abbreviation as a browser functionality. If the
> TITLE-attribute wasnÂt styled, You would probably not try to hover to get
> information. The titled abbreviation just looks like any other textelement.
> Styling would help You, if You are sighted and can use the mouse. Even if
> You need a magnification software, You benefit of the visual indication.
> If You need a screen reader, the information You get, depends on Your
> settings and not on the styling. But this is an other issue.
> <span lang="de" title="best regards">Beste GrüÃe!</span>
> Wolfgang
You're tackling the problem from the "we should make the fact there's a
title attribute on a random element visually clear", whereas the general
advice really is "don't use title attribute in general".
With the exception of MS Edge, no browser shows title attribute tooltips
even on focusable elements. Arbitrary, non-focusable elements with title
of course never show their title in any browser.
Instead of making the use of title more enticing with styling, we should
focus on avoiding title usage. For some elements like
acronyms/abbreviations, title has a clearly defined additional benefit
and per spec the expanded version of the acronym/abbreviation goes in
the title. But for arbitrary elements, you're really still just working
on something that for mouse users happens to provide a tooltip, but is
useless to most other users.
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: Birkir R. Gunnarsson
Date: Sat, Nov 11 2017 7:02AM
Subject: Re: Available title indication via css
← Previous message | Next message →
The title attribute has been supported in HtML for decades. Why should
the fact that browser vendors fail to support it make it bad for
accessibility?
If we always go by the "it's valid but no one supports it, don't use
it" we'd still be in the age of static HTML.
Isn't the point of standards to ensure authors can create universally
accessible content without having to code for the nuances of how
different user agents handle it, isn't that the responsibility of the
usre agents?
I discourage, well forbid, the user of title attributes on non
focusable elements (with the exception of abbreviations and
definitions, provided that the expanded form is available in text the
first time the abbreviation/definition is used in the document), but
there is no reason why the title attribute should not be accessible to
keyboard only users if the browser vendors did their part. It is
available to most popular screen reader/browser combinations (thanks
in large part to the accessible name calculation specification).
Why isn't the HTML standard updated to allow the title attribute on
generic or non focusable elements (other than where it has a special
purppose, and on images), but allow it on focusable elements, and push
browser vendors to display it on keyboard focus. That, or drop the
title attribute from the spec.
The "it's there, it's valid, it's been there forever, yet you
can't use it" approach is exactly why mainstream developers get so
frustrated tackling accessibility.
On 11/11/17, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 11/11/2017 10:26, Wolfgang Berndorfer wrote:
>> Hi Bim,
>> Don't only think of people with disabilities. Imagine, You find an
>> abbreviation on a website, You don't understand: If the abbreviation is
>> visually perceivable as titled, You will hover with your mouse and get the
>> meaning of the abbreviation as a browser functionality. If the
>> TITLE-attribute wasn't styled, You would probably not try to hover to get
>> information. The titled abbreviation just looks like any other
>> textelement.
>> Styling would help You, if You are sighted and can use the mouse. Even if
>> You need a magnification software, You benefit of the visual indication.
>> If You need a screen reader, the information You get, depends on Your
>> settings and not on the styling. But this is an other issue.
>> <span lang="de" title="best regards">Beste GrüÃe!</span>
>> Wolfgang
>
> You're tackling the problem from the "we should make the fact there's a
> title attribute on a random element visually clear", whereas the general
> advice really is "don't use title attribute in general".
>
> With the exception of MS Edge, no browser shows title attribute tooltips
> even on focusable elements. Arbitrary, non-focusable elements with title
> of course never show their title in any browser.
>
> Instead of making the use of title more enticing with styling, we should
> focus on avoiding title usage. For some elements like
> acronyms/abbreviations, title has a clearly defined additional benefit
> and per spec the expanded version of the acronym/abbreviation goes in
> the title. But for arbitrary elements, you're really still just working
> on something that for mouse users happens to provide a tooltip, but is
> useless to most other users.
>
> 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
> > > > >
--
Work hard. Have fun. Make history.
From: Wolfgang Berndorfer
Date: Sat, Nov 11 2017 7:40AM
Subject: Re: Available title indication via css
← Previous message | Next message →
Hi Patrick,
I know the usage an abuses of the TITLE-atribute.
But I consider the Âfirst usage rule as a forensic plaster: Expand in plain
text in first instance! If You do, You pass WCAG.
But: Who reads a website from top left to bottom right? And why are we
demanding navigable headings or sections? ItÂs very easy and probable to
miss the first instance, when You visit a site applying navigational offers.
When IÂm personally surfing IÂm listening to what my screen reader says and
if I donÂt understand something, I look at the monitor using ZoomText. And
itÂs very helpful for me and all those, who didnÂt read from top left
continuously, when thereÂs still additional information via TITLE available.
Admittedly not for everyone and unfortunately not for blind and other
non-mouse users.
Here we come to the fundamental discussion: Is allowed, what is helpful for
some, but inaccessible for others? And my other question: Is enough, what is
forensically accessible, but causes predictable usability issues?
These moral question could be interesting new threats.
Best regards!
Wolfgang
Zweiter Blick - Für ein barrierefreies Web
Mag. Wolfgang Berndorfer
Akademischer Experte für Barrierefreies Webdesign
A-6020 Innsbruck, Schidlachstr. 9/3
T: +43 (0) 512 / 560 568
M: +43 (0) 664 / 734 934 05
= EMAIL ADDRESS REMOVED =
http://www.zweiterblick.at
Diese Nachricht und allfällige angehängte Dokumente sind nur für den
Adressaten bzw. die Adressatin bestimmt. Sollten Sie versehentlich dieses
E-Mail erhalten, ist jede Offenlegung, Weiterleitung oder sonstige
Verwendung dieser Information nicht gestattet. In diesem Fall bitten wir,
uns zu verständigen und die Information zu vernichten.
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
von Patrick H. Lauke
Gesendet: Samstag, 11. November 2017 13:43
An: = EMAIL ADDRESS REMOVED =
Betreff: Re: [WebAIM] Available title indication via css
On 11/11/2017 10:26, Wolfgang Berndorfer wrote:
> Hi Bim,
> DonÂt only think of people with disabilities. Imagine, You find an
> abbreviation on a website, You donÂt understand: If the abbreviation is
> visually perceivable as titled, You will hover with your mouse and get the
> meaning of the abbreviation as a browser functionality. If the
> TITLE-attribute wasnÂt styled, You would probably not try to hover to get
> information. The titled abbreviation just looks like any other
textelement.
> Styling would help You, if You are sighted and can use the mouse. Even if
> You need a magnification software, You benefit of the visual indication.
> If You need a screen reader, the information You get, depends on Your
> settings and not on the styling. But this is an other issue.
> <span lang="de" title="best regards">Beste GrüÃe!</span>
> Wolfgang
You're tackling the problem from the "we should make the fact there's a
title attribute on a random element visually clear", whereas the general
advice really is "don't use title attribute in general".
With the exception of MS Edge, no browser shows title attribute tooltips
even on focusable elements. Arbitrary, non-focusable elements with title
of course never show their title in any browser.
Instead of making the use of title more enticing with styling, we should
focus on avoiding title usage. For some elements like
acronyms/abbreviations, title has a clearly defined additional benefit
and per spec the expanded version of the acronym/abbreviation goes in
the title. But for arbitrary elements, you're really still just working
on something that for mouse users happens to provide a tooltip, but is
useless to most other users.
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: Patrick H. Lauke
Date: Sat, Nov 11 2017 8:44AM
Subject: Re: Available title indication via css
← Previous message | Next message →
On 11/11/2017 14:02, Birkir R. Gunnarsson wrote:
> The title attribute has been supported in HtML for decades. Why should
> the fact that browser vendors fail to support it make it bad for
> accessibility?
> If we always go by the "it's valid but no one supports it, don't use
> it" we'd still be in the age of static HTML.
Compared to what? Having a pleasant feeling of "hey I'm using a valid
technique...not my problem if users can't actually use it because
browsers don't support it, not MY problem"?
> Isn't the point of standards to ensure authors can create universally
> accessible content without having to code for the nuances of how
> different user agents handle it, isn't that the responsibility of the
> usre agents?
Well, have fun continuing trying to get browser vendors to change their
behavior.
> I discourage, well forbid, the user of title attributes on non
> focusable elements (with the exception of abbreviations and
> definitions, provided that the expanded form is available in text the
> first time the abbreviation/definition is used in the document), but
> there is no reason why the title attribute should not be accessible to
> keyboard only users if the browser vendors did their part.
See above. Right here, right now, only MS Edge keyboard users can
trigger a title tooltip. We can argue here that there's no reasons
browsers shouldn't do this as well, but the reality is that they don't.
> It is
> available to most popular screen reader/browser combinations (thanks
> in large part to the accessible name calculation specification).
Good, but that doesn't help other user groups.
> Why isn't the HTML standard updated to allow the title attribute on
> generic or non focusable elements (other than where it has a special
> purppose, and on images), but allow it on focusable elements, and push
> browser vendors to display it on keyboard focus. That, or drop the
> title attribute from the spec.
>
> The "it's there, it's valid, it's been there forever, yet you
> can't use it" approach is exactly why mainstream developers get so
> frustrated tackling accessibility.
And yet, it's the reality we have to deal with right here, right now.
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: Patrick H. Lauke
Date: Sat, Nov 11 2017 8:47AM
Subject: Re: Available title indication via css
← Previous message | Next message →
On 11/11/2017 14:40, Wolfgang Berndorfer wrote:
[...]
> Here we come to the fundamental discussion: Is allowed, what is helpful for
> some, but inaccessible for others?
If you provide content only perceivable by one user group, you're
discriminating/disadvantaging other user groups.
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: Wolfgang Berndorfer
Date: Sat, Nov 11 2017 9:37AM
Subject: Re: Available title indication via css
← Previous message | Next message →
For WCAG standards I don't discriminate, when I use title attribute, as far
as I expand in first instance: Everybody can find the meaning in first
instance on the page. My point is that is not enough for usability.
And the metaproblem stays: Is it a discrimination to help some people with
functionality, which is not available general. My opinion: It is no
discrimination. Nobody would forbid graphic organigramms for instance,
because their complex informations about relations can textually only be
explained too verbously.
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
von Patrick H. Lauke
Gesendet: Samstag, 11. November 2017 16:47
An: = EMAIL ADDRESS REMOVED =
Betreff: Re: [WebAIM] Available title indication via css
On 11/11/2017 14:40, Wolfgang Berndorfer wrote:
[...]
> Here we come to the fundamental discussion: Is allowed, what is helpful
for
> some, but inaccessible for others?
If you provide content only perceivable by one user group, you're
discriminating/disadvantaging other user groups.
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: Birkir R. Gunnarsson
Date: Sat, Nov 11 2017 9:54AM
Subject: Re: Available title indication via css
← Previous message | Next message →
There are two ways forward to resolve this problem in the longer term.
Either get the browser vendors to support the title ttribute properly,
or drop it from the spec.
And, yes, if I use an HTML attribute properly, according to the
definition of its use, it could be argued that it is not my problem if
users cant perceive it )or at least it is not only my problem).
I can blame the browser vendors, or I can tell my keyboard only users
to switch to Microsoft Edge, or file an issue with the browser they
prefer.
I understand the dilemma, I feel it every day. Should I recommend not
using a valid attribute, because I don't want to discriminate against
my clients, but I also feel the pull of an achieveable, affordable
universal access, which is that the authors cannot, and should not, go
out of their way and not use semantically correct HTML because someone
else in the chain is not doing their duty, whether it is the browser
or the user agent.
I feel we ckeep dodging the real problem when we keep telling people
they can't use the title attribute. The fundamental problem is, why
can't they? Is it impossible for the browser vendors to support it? If
so, it shouldn't be in the specification. Or is it that the vendors
don't care, or don't put enough priority on this problem. Then we have
to ask why, and how that can be changed.
I understand the pull, and the delicate balance we face, ultimately we
need to make sure all our users can access our content. But in order
to have a long-term success we also have to work on the standards or
the user agents have to do their job.
Why does the standard allow the title attribute on non focusable
elements? Isn't that a fundamental discrimination against people with
disabilities in herent in the very specification behind web pages?
Yes, it shouldn't be used for essential information about an element,
but if it is used by any information, and that information is not
accessible to certain group of users, why is it valid use?
I don't pretend to have the answers, I admit that, but I think the
question needs to be askked by now and together we may find those
answers, not for today but for the future.
On 11/11/17, Wolfgang Berndorfer < = EMAIL ADDRESS REMOVED = > wrote:
> For WCAG standards I don't discriminate, when I use title attribute, as far
> as I expand in first instance: Everybody can find the meaning in first
> instance on the page. My point is that is not enough for usability.
>
> And the metaproblem stays: Is it a discrimination to help some people with
> functionality, which is not available general. My opinion: It is no
> discrimination. Nobody would forbid graphic organigramms for instance,
> because their complex informations about relations can textually only be
> explained too verbously.
> >
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
> von Patrick H. Lauke
> Gesendet: Samstag, 11. November 2017 16:47
> An: = EMAIL ADDRESS REMOVED =
> Betreff: Re: [WebAIM] Available title indication via css
>
> On 11/11/2017 14:40, Wolfgang Berndorfer wrote:
> [...]
>> Here we come to the fundamental discussion: Is allowed, what is helpful
> for
>> some, but inaccessible for others?
>
> If you provide content only perceivable by one user group, you're
> discriminating/disadvantaging other user groups.
>
> 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
> > > > >
> > > > >
--
Work hard. Have fun. Make history.
From: Chagnon | PubCom
Date: Sat, Nov 11 2017 11:27AM
Subject: Re: Available title indication via css
← Previous message | Next message →
Love what Birkir said!
He so clearly defines the underlying issue. (I've repeated his post at the end.)
There are 4 stakeholder groups in accessibility:
1. The organizations that develop the standards, such as the WCAG, EPUB, and PDF/ U A committees.
2. The content creators who have to build their material to meet the standards.
3. The vendors who must create the tools to deliver and interpret the content per the standards. This group includes the vendors who make our content creation tools, such as Microsoft and Adobe; the vendors who create our delivery applications, such as our browsers and EPUB readers; and the vendors who create our A T and user agents.
4. The end user, which includes everyone whether they're using A T or not.
Personally, I'm a member of all 4 stakeholder groups, wearing 4 different hats every day.
The first group, the committees, are doing fantastic work.
The second group, content creators, are learning the ropes. More people today know how to make accessible content then 10 years ago, but this group will always be a work in progress. Kudos to those putting accessibility into their action plans.
The third group, all 3 types of vendors, haven't stepped up to the plate or haven't done enough. They are failing us.
And the reason is because we users have not forced them to keep their part of the accessibility deal. We have not held their feet to the fire, to the standards.
These companies are on the standards committees, so they know exactly what is required of their firms, their software, and their A T devices. But their companies do not implement the standards they help develop. The standards are ignored and, consequently, so too the people who depend upon those standards.
It's civil rights discrimination. Let's not forget that the most critical of these vendors are the largest, most profitable entities in the world. They can't cite financial hardship or lack of programming talent.
So don't water down the standards...well, unless an item really needs to be retooled or yanked, but think long and hard about removing items from standards. After a while, no one will trust your standard at all!
The weakest link of accessibility is the vendors--all of them. Stop buying their products. Stop using their apps. And tell them why you're doing this. Make your requests on their websites' wish list (search for "company name" + "wishlist") and tell them how their product is failing and what you'd like them to do.
And if a product, app, or service still doesn't meet the standards, then think about suing the company. Sometimes that's the only way the suits in the boardroom will get the message and direct their employees (and fund the R and D costs) to correct the shortcomings.
If you're with a government agency, school, or other large institutional, then tell the vendors you'll pull their software off your computer systems because it's not fully meeting accessibility requirements. Vote with your wallet.
Now, on the other side...
A shout out to Microsoft, Adobe, and Google...3 of the major product developers that affect our lives. Over the past couple of years, they have stepped up their commitment and work on accessibility. It's beginning to show in recent and forthcoming software versions.
An example: last week Adobe shipped the latest version of InDesign, the leading page layout program that is used to create nearly all of the textbooks, newspapers, periodicals, marketing materials, instruction and reference manuals, and books produced worldwide. InDesign is also central to creating EPUBs and other digital versions of these materials.
InDesign CS 2018 (a k a version 13) can now produce a near fully accessible PDF that is compliant with the PDF / U A-1 standard. Footnotes, anchored text frames, tables of content (and other lists), and more are all now "do-able" by the graphic designer. No -- or very little -- remediation is needed after the PDF is created.
Thank you to the team at Adobe that made this happen. (I know some are on this list.) It didn't happen overnight; development of InDesign's accessibility tools took about 7 years, with a huge push in the last 2.
Thank you.
For those who use InDesign, I'm teaching a 1 day workshop on accessible PDFs with InDesign on Tuesday at next week's AHG (accessing higher ground) conference in Westminster. There might still be some seats available.
--Bevi Chagnon
â â â
Bevi Chagnon | www.PubCom.com
Technologists for Accessible Design and Publishing
print â digital â web â documents â pdfs â epubs
consulting â training â development â design â sec. 508 services
â â â
From: Wolfgang Berndorfer
Date: Sun, Nov 12 2017 12:44PM
Subject: Re: Available title indication via css
← Previous message | No next message
Hi all,
My personal interim summary:
Thanks for the interesting discussion and imputs! I try to sum up under the
viewpoint of my original question, which I'd like to precise like this:
Is a visual indication for the existence of a title-attribute on an element
via styling necessary?
Answer:
1. Visual Indicators for the existence of a title-attribute are helpful for
sighted users with the ability to trigger hover-effects with their mouse and
should therefore be considered as necessary. [At least there where no
objections against the substance of this statement.]
2. The visual indication of the existence of a title-attribute is neither
necessary nor sufficient for WCAG conformance when using title-attributes.
It's simply an issue of usability for sighted mouse users.
3. The helpfulness of a title-information not only in the first instance
results from navigational strategies of users which can cause a skip over
the first instance.
BUT don't forget the general accessibility problems of the thitle attribute:
1. The title-attribute ist not available for keyboard-only usage except
a) in MS Edge [didn't look for detailed implementation] and
b) for some elements via screen reader functionalities depending on
settings. (e.g. abbr-attribute presented as abbreviation or expanded)
2. Therefore the first instance of an element to get title-informations MUST
present the information in plain text, which means automatically visible on
screen and anounced by screen readers. (e.g. meaning of an abbreviation,
translation of foreign language element, .)
Wolfgang