[Central-md-chapter] FW: Regions and Landmarks on WebSites and other info

[Joe Schissler]

Hello All,  The forwarded email contains some info Mistra found for me.
Most of the info I found to be somewhat interesting at first - then it got
way over my head.  The reason I'm forwarding this is at the very bottom of
her message, so skip to the bottom and check out Mistra's short note and the
link at the very end.  It was written by a web developer who pretended to be
blind and tried to access various websites, with little success.  I had to
say "Amen" to all his comments.

Joe


-----Original Message-----
From: Moazami, Mistra [mailto:Mistra.Moazami at jhuapl.edu] 
Sent: Monday, July 06, 2015 9:32 AM
To: 'Joe Eleanor Schissler (jandes1 at verizon.net)'
Subject: Regions and Landmarks on WebSites

Joe:

In trying to find out what Regions and Landmarks in web pages are and how
they are supposed to help I came across the following information from the
World Wide Web Consortium (W3C).  They have a "Web Accessibility Initiative"
(WAI) and are working on standards called Accessible Rich Internet
Applications.  Landmarks and Regions are features for web sites they have
defined to make web pages more accessible.  But I don't know how actively
they are pushing things or if there are any regulations requiring developers
to incorporate them.  I have included some more details below for your
amusement.  Let me know if you want  me to dig deeper.

Link to WAI-ARIA web site where I found this information is
http://www.w3.org/WAI/PF/aria/

Which describes what they landmarks and regions are, but does not explain
how as a blind person you would utilize them.

Landmark:  A type of region on a page to which the user may want quick
access. Content in such a region is different from that of other regions on
the page and relevant to a specific user purpose, such as navigating,
searching, perusing the primary content, etc.

Live Region:  Live regions are perceivable regions of a web page that are
typically updated as a result of an external event when user focus may be
elsewhere. These regions are not always updated as result of a user
interaction. This practice has become commonplace with the growing use of
Ajax. Examples of live regions include a chat log, stock ticker, or a sport
scoring section that updates periodically to reflect game statistics. Since
these asynchronous areas are expected to update outside the user's area of
focus, assistive technologies such as screen readers have either been
unaware of their existence or unable to process them for the user. WAI-ARIA
has provided a collection of properties that allow the author to identify
these live regions and how to process them: aria-live, aria-relevant,
aria-atomic, and aria-busy


Web Accessiblity Initiative - Accessible Rich Internet Application
(WAI-ARIA) Version 1.0 drafted February 2014
Editors:  James Craig, Apple Inc.;    Michael Cooper, W3C
Previous Editors: Lisa Pappas, Society for Technical Communication;    Rich
Schwerdtfeger, IBM;   Lisa Seeman, UB Access

The domain of web accessibility defines how to make web content usable by
persons with disabilities. Persons with certain types of disabilities use
assistive technologies (AT) to interact with content. Assistive technologies
can transform the presentation of content into a format more suitable to the
user, and can allow the user to interact in different ways. For example, the
user may need to, or choose to, interact with a slider widget via arrow
keys, instead of dragging and dropping with a mouse. In order to accomplish
this effectively, the software needs to understand the semantics of the
content. Semantics is the science of meaning; in this case, used to assign
roles, states, and properties that apply to user interface and content
elements as a human would understand. For instance, if a paragraph is
semantically identified as such, assistive technologies can interact with it
as a unit separable from the rest of the content, knowing the exact
boundaries of that paragraph. An adjustable range slider or collapsible list
(a.k.a. a tree widget) are more complex examples, in which various parts of
the widget have semantics that need to be properly identified for assistive
technologies to support effective interaction.

New technologies often overlook semantics required for accessibility, and
new authoring practices often misuse the intended semantics of those
technologies. Elements that have one defined meaning in the language are
used with a different meaning intended to be understood by the user.   For
example, web application developers create collapsible tree widgets in HTML
using CSS and JavaScript even though HTML has no semantic tree element. To a
non-disabled user, it may look and act like a collapsible tree widget, but
without appropriate semantics, the tree widget may not be perceivable to, or
operable by, a person with a disability because assistive technologies may
not recognize the role.    The incorporation of WAI-ARIA is a way for an
author to provide proper semantics for custom widgets to make these widgets
accessible, usable, and interoperable with assistive technologies. This
specification identifies the types of widgets and structures that are
commonly recognized by accessibility products, by providing an ontology of
corresponding roles that can be attached to content. This allows elements
with a given role to be understood as a particular widget or structural type
regardless of any semantic inherited from the implementing host language.
Roles are a common property of platform accessibility APIs which assistive
technologies use to provide the user with effective presentation and
interaction.

This role taxonomy includes interaction widgets and elements denoting
document structure. The role taxonomy describes inheritance and details the
attributes each role supports. Information about mapping of roles to
accessibility APIs is provided by the WAI-ARIA User Agent Implementation
Guide [ARIA-IMPLEMENTATION].   Roles are element types and will not change
with time or user actions. Role information is used by assistive
technologies, through interaction with the user agent, to provide normal
processing of the specified element type.   States and properties are used
to declare important attributes of an element that affect and describe
interaction. They enable the user agent and operating system to properly
handle the element even when the attributes are dynamically changed by
client-side scripts. For example, alternative input and output technology,
such as screen readers and speech dictation software, need to be able to
recognize and effectively manipulated and communicate various interaction
states (e.g., disabled, checked) to the user.

It goes on and on... pretty technical and targetted towards web
developers.....


I found this web page interesting.  A web developer pretended to be blind
for a week and tried using the internet.  Thought you might enjoy reading
what he found - link is below:
https://silktide.com/things-i-learned-by-pretending-to-be-blind-for-a-week/