You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two different ALT's involved here - one on the IMG referencing the MAP AREAs and the ALT on each AREA - and there could be null ALTs on either element (or both elements). This poses a few questions:
Should the accessible name of an AREA be a combination of both IMG ALT and AREA ALT? That could get very verbose with the example above when reading each AREA link.
If not a combination then should IMG ALT be exposed in some other way, such as mapping IMG ALT to AREA link accessible description?
What should happen when IMG has null ALT, but IMG USEMAP references MAP AREAs with non-null ALT? Should it set the image to role=presentational, even though the USEMAP attribute says the image isn't presentational? If AREA is voiced as a combination of IMG ALT and AREA ALT then there will be cases where you don't want any IMG ALT to reduce verbosity.
What should happen when IMG has non-null ALT, but AREA has a null ALT?
To get an idea of UA differences currently:
NVDA 2018 with FF60 voices IMG ALT and AREA ALT as link title
JAWS 2018 with IE11 voices AREA ALT as link title
JAWS 2018 with FF60 voices AREA HREF as link title
VoiceOver with Safari on macOS 10.13 voices AREA ALT as link title
VoiceOver with Safari on iOS 11.4 voices AREA ALT as link title, but only reads IMG ALT (and not AREA ALT) when the speak screen gesture is used (i.e. no link roles read, and no indication AREA links exist - the only way to find the AREA links seems be setting rotor is set to Links, and using the move to next rotor item gesture )
Picking this up and will clarify. But in the meantime I can tell you that what some screen readers are announcing is not necessarily just the accessible name, but rather a mish mashing of different data.
For instance, with Firefox MSAA and IA2 are exposing the area's alt as the accessible name, the URL as the accValue/Value, and MSAA exposes the image's alt as the accParent.
area
isn't listed in the Accessible Name and Description Computationhttps://www.w3.org/TR/html-aam-1.0/#accessible-name-and-description-computation
although it is listed in HTML Element Role Mappings
https://www.w3.org/TR/html-aam-1.0/#el-area
There are two different ALT's involved here - one on the IMG referencing the MAP AREAs and the ALT on each AREA - and there could be null ALTs on either element (or both elements). This poses a few questions:
To get an idea of UA differences currently:
MDN page here:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/area
WCAG technique here:
https://www.w3.org/TR/WCAG20-TECHS/H24.html
Tested support here:
https://www.powermapper.com/tests/screen-readers/labelling/area-alt/
https://www.powermapper.com/tests/screen-readers/labelling/area-alt-img-null-alt/
https://www.powermapper.com/tests/screen-readers/labelling/area-title/
https://www.powermapper.com/tests/screen-readers/labelling/area-aria-label/
https://www.powermapper.com/tests/screen-readers/labelling/area-aria-labelledby/
The text was updated successfully, but these errors were encountered: