w3c / wai-website Goto Github PK

I found [acronym]EC[/acronym]. Maybe is [acronym title="European Commission"]EC[/acronym]

Needs WAI and WG info.

Also Contents.

draft at https://w3c.github.io/wai-sitemap/

We need an approach for packaging changelogs and resource descriptions (like requirements analysis) with each resource, so we can consistently link to is and reliably find it. Maybe using the README files on GitHub could work, or wikis or pages in the resource.

Prompted by: w3c/wai-older-users#12 (comment)

Consider providing a list/database of example policies.

Related to w3c/wai-policies-prototype#328 & w3c/wai-policieslist#2

Icon before link "Skip to content" appears as representation of a drop down menu and misrepresents.

From @srinivasuchakravarthula on March 20, 2018 6:46

As we normally don't recommend use of <uppercase> for things other than abbreviations, I think we should change link text of "Get Involved" and "About W3C WAI (ABOUT world)" to none. This improves readability.

Copied from original issue: w3c/wai-tutorials#550

Thelonius Mank

Menus should be collapsed when user uses escape key. Considering user may accidentally activates menu and if there is no provision to instantly collapse, user may have to navigate through all the navigation items.

From @nitedog

For later (please log somewhere):
Something odd about pointing out individual personas and videos with older people. For example, the captions video is also relevant to older people, even if it doesn't happen to feature anyone. Maybe we just need some explanatory sentence about universal design, or maybe reference to accessibility/usability/inclusion page when ready.

via Howard – The navigation is hard to see, needs more affordance.

I don't found any H1 at Homepage

Hi,

https://www.w3.org/WAI/beta/fundamentals/accessibility-intro/

This page is a great collection of information. It feels a bit long though. Is it possible to split this into individual sections? Looking at a mobile screen, it scrolls forever.

On that note, there are multiple <aside> tags used to section some complementary areas under each content section. They are not labelled with Aria-label or as such. For users using screen reader's landmark navigation, they might need Labels to distinguish them.

Thanks,
Herin

Hi,

related to #26
https://www.w3.org/WAI/beta/tips/designing/

Thanks,
H

more like this -- at least so the hanging indents / left margins are the same alignment

https://www.w3.org/WAI/beta/plan/interim-repairs/

This doesn't map to a specific WCAG criteria, but I believe that tweaking the design of the header will make it feel less dense and easier to understand at a glance. This will be helpful to users with cognitive disabilities while also presenting a more polished interface. Here are my recommendations:

• Increase top and bottom padding of header

• Increase vertical spacing between content within header, including dropdown. This make it easier to digest the content at a glance and also improve users' ability to tap on the intended target in mobile.

• I'm not sure that the tagline is necessary, but if you keep it, then I suggest moving it closer to the logo to cement the visual association. Right now, it feels as though it's floating.

• The use of a border to the left of the tagline and the second item in the meta nav is confusing because, at some screen sizes, it appears that the borders are actually group the tagline with the first meta nav item. (See Screenshot.) I like the border on the tagline, but why don't we use a middle dot (·) to separate meta nav items instead? Middle dots have been used as text dividers for hundreds of years, so they are a typographic choice with greater precedent.

• I suggest adjusting the breakpoints so that the meta nav and search wrap to a second line when the window is smaller than ~ 1300 px. Right now, the nav appears pretty squished at ~ 950 px and just feels really difficult to read. (See Screenshot.)

• Increase the left and right padding of the header in mobile to match that of the content below.

• In mobile, the meta nav becomes visually lost. I suggest left aligning the text.

• I realize there aren't guidelines around this, but I feel it would be difficult for users to tap on the meta nav links and/or the search field in mobile. Increasing vertical spacing will help with that, but why not also place each meta nav item on its own line and make the search field full width?

Hi,

Looking into the page https://www.w3.org/WAI/beta/planning-and-managing/initiate/.
The + and - works fine with a mouse, keyboard. But, when NVDA is on it does not work. Checked in Chrome.

Can someone please try to reproduce the same in JAWS?

Thanks

via Sarah

Hi,

Most of the pages including the https://www.w3.org/WAI/beta/fundamentals/components/ page contain a summary section before the Page content section.

But, this is not consistent across. The summary is missing in some of the pages.
https://www.w3.org/WAI/beta/people-use-web/tools-techniques/

Maybe this is intentional due to different templates. But, I think a small summary introduces the context of the page to the users. Just a recommendation.

Thanks,

https://app.zeplin.io/project.html#pid=58da7fb05d831f2441ed1c0a&sid=58da800524555267b14fa6be

Hi,

I was expecting the Skip to content navigation to take me to the "actual content" area in this page.

https://www.w3.org/WAI/beta/about/#main

But, apparently, the "other pages in this resource" navigation is part of the main and hence keyboard focus transfers to this. I do not think this should be in the main content area.

Thanks,

When I first came to the idea of web accessibility and 'readability' I was gobsmacked to see the use of the term 'conformance'. This audience includes people reading English as a second language and those requiring readability levels lower than academic. I suggest the w3c WAI retires the term conformance in favour of:

• conform
• to conform
• conformed

I say this imagining that the term 'comply' was not used as an active choice previously and that the same considerations may apply now.

Rgds,

Chris.

Menus shouldn't open on initial hover.
Instead, only open if the user clicks, or types enter/space, on a menubar item.
If a menu is already open, it is ok to open another menu if the user hovers over that menubar item.

That way, you know that the user actually intended to look into the menus; you are not making any assumptions for them.

This blog post describes some problems with hover menus.

For me, even though I know that hover menus are everywhere, it still startles me, every time I happen to move the mouse over a menubar, to have something unexpectedly fly in my face and obscure what I was just about to read.

Priority: Medium
Location: Introduction paragraph
Current Wording:

This document presents a recommended format for communicating results of the evaluation of Web site accessibility according to the Web Content Accessibility Guidelines (WCAG) 2.0. A consistent and comprehensive evaluation report format can help ensure effective evaluations as well as accurate comparisons of accessibility levels over time and between different Web sites.

Suggested Revision:

This document presents a recommended format for communicating results of the evaluation of Web site or Web application accessibility according to the Web Content Accessibility Guidelines (WCAG) 2.0. A consistent and comprehensive evaluation report format can help ensure effective evaluations as well as accurate comparisons of accessibility levels over time and between different sites and applications.

Rationale: Want users to know that this eval report can be used for reporting on web apps as well as web sites.

Hi, I'm a bit concerned about the menu structure you currently use :

<li class="has-submenu">
    <a href="/sitemap/#accessibility-fundamentals" aria-haspopup="true" aria-expanded="false"><span>Accessibility Fundamentals</span></a>
</li>
<li role="presentation" class="subnav">
    <div class="col1">
        <ul class="subnavcontent">
            <li class=""><a href="/wai-website/fundamentals/accessibility-intro/" aria-haspopup="true" aria-expanded="false"><span>Introduction to Accessibility</span></a></li>
            <li class=""><a href="/wai-website/fundamentals/components/" aria-haspopup="true" aria-expanded="false"><span>Components of Web Accessibility</span></a></li>
            <li class=""><a href="/wai-website/fundamentals/accessibility-principles/" aria-haspopup="true" aria-expanded="false"><span>Accessibility Principles</span></a></li>
            <li class=""><a href="/wai-website/perspective-videos/" aria-haspopup="true" aria-expanded="false"><span>Perspectives Videos</span></a></li>
        </ul>
    </div>
    <div class="col2">...</div>
    <div class="col3">...</div>
</li>

It's semantically wrong.
First there is no relationship between first level and sublevel,
Then you use a ul for each column when it's in fact only one list presented with columns
Lastly you use aria-haspopup="true" aria-expanded="false" on link of submenu and there is no need for it

I think if you want to use aria for the list this kind of structure will be better :

<li class="has-submenu">
    <a href="/sitemap/#accessibility-fundamentals" aria-haspopup="true" aria-expanded="false"><span>Accessibility Fundamentals</span></a>
    <div class="subnav" role="list">
        <div class="col1" role="presentation">
            <div class="subnavcontent"  role="presentation">
                <div class="" role="listitem"><a href="/wai-website/fundamentals/accessibility-intro/"><span>Introduction to Accessibility</span></a></div>
                <div class="" role="listitem"><a href="/wai-website/fundamentals/components/"><span>Components of Web Accessibility</span></a></div>
                <div class="" role="listitem"><a href="/wai-website/fundamentals/accessibility-principles/"><span>Accessibility Principles</span></a></div>
                <div class="" role="listitem"><a href="/wai-website/perspective-videos/"><span>Perspectives Videos</span></a></div>
            </div>
        </div>
        <div class="col2" role="presentation">...</div>
        <div class="col3" role="presentation">...</div>
    </div>
</li>

otherwise it must be :

<li class="has-submenu">
    <a href="/sitemap/#accessibility-fundamentals" aria-haspopup="true" aria-expanded="false"><span>Accessibility Fundamentals</span></a>
    <ul class="subnav">
        <li class="col1"><a href="/wai-website/fundamentals/accessibility-intro/"><span>Introduction to Accessibility</span></a></li>
        <li class="col1"><a href="/wai-website/fundamentals/components/"><span>Components of Web Accessibility</span></a></li>
        <li class="col1"><a href="/wai-website/fundamentals/accessibility-principles/"><span>Accessibility Principles</span></a></li>
        <li class="col1 last"><a href="/wai-website/perspective-videos/"><span>Perspectives Videos</span></a></li>
        <li class="col2">...</li>
        ...
        <li class="col2 last">...</li>
        <li class="col3">...</li>
        ...
        <li class="col3 last">...</li>
    </ul>
</li>

Attached file has Comments and tracked changes for consideration.

selecting-eval-tools.docx

Currently, if a menubar item has focus, the menu can be opened with Enter.
That's great, but they should also open with Space, Down arrow, and even Up arrow.

Then, once a menu is open, typing Tab moves focus through the menu item links in sequential order.
That's ok base functionality, but I think that up/down arrows (and even right/left arrows) should also focus the menu item links in row/column order, wrapping as needed.

Of course, Esc should close an open menu, but I think you already have a issue for that.

I kept clicking the boxes on the homepage "W3C", "WAI", and "You" until I figured that they are not interactive tiles but only static information.

Have left side Related Links section include all 6 Tips pages?

https://www.w3.org/WAI/intro/components -> https://www.w3.org/WAI/intro/components.php

Maybe include something along the lines of: The Before and After Demonstration (BAD) includes reports on how each page conforms to WCAG 2.0. For example, see the Inaccessible Home Page Report.

Hi,

In this page, the links on the left-hand navigation seem to be fine. But, the ones below the images and the linked images take to the link https://www.w3.org/perspective-videos/keyboard/ resulting in 404 error.

https://www.w3.org/WAI/beta/perspective-videos/

Thanks

How to tackle?

pros and cons to both approaches.

probably good to have the same throughout the document.
(consistency is generally best... although mixin' it up has advantages in some situations...

When the new Mobile Accessibility Introduction is done -- or maybe even when it's a polished draft -- add clear pointers to it.

Currently the drop down main menu is tab driven... consider the wai-aria authoring practices model.
https://www.w3.org/TR/wai-aria-practices-1.1/#menu

Where the user tabs into the menu and uses arrow keys to navigate once inside.
If this model is not chosen and tab is used to move through the list of links, then I think a response on why not would be good, because there is an active discussion about whether a tab navigated menu should be included in the authoring practices document.
w3c/aria-practices#492

At least trap the esc key to close the menu.

At a high level, where in the existing site content should we begin to integrate mobile-specific information? For example: tutorials, Tips for Getting Started, etc.

Understand issues and what we want to do with clearing it and/or auto-populating it -- or disabling it.

(some surprising stuff in there already)

Breadcrumbs are not getting updated to show the exact location on some pages.

https://www.w3.org/WAI/beta/fundamentals/accessibility-intro/
https://www.w3.org/WAI/beta/fundamentals/components/
https://www.w3.org/WAI/beta/fundamentals/accessibility-principles/

Thanks,
Herin

Can we make these more visible?

At a minimum, can we add a space between the word and the arrows?

@michael-n-cooper & Judy

Should https://www.w3.org/TR/html-aria/

be listed in the ARIA Overview page and in https://www.w3.org/TR/#tr_Accessibility__All_

?

The default focus state—and a slight colour change for links—is currently all that is used to indicate focus. Wouldn’t it be better to add custom focus states that are a bit clearer?

Hi,

In page https://www.w3.org/WAI/beta/perspective-videos/, there is a For presentations: compilation of all 10 videos (7:36 minutes) link that takes to youtube.

I think it's a best practice to let the visual and screen reader users know it is an external link.

Current code:
<a href="https://www.youtube.com/watch?v=3f31oufqFSM">compilation of all 10 videos (7:36 minutes)</a>

Thanks

The homepage news item headings, like "Graphics-ARIA and Graphics-AAM wide review drafts", have a faint blue that look like a link. It took me a while to understand that I need to select the date(!) to expand the news item and get additional information. Why not make that heading a link too? Or add a "read more"?

For Editors discretion.

Suggest changing "If it is a government website, contact your local government." to "If it is a government website, contact your local government representative." (or parliamentarian? but not usually an appropriate term for municipal government)

think about what to say about the article.

want to provide credibility.

Example of simple policy
ACME Inc. is committed to ensuring that its website is accessible to people with disabilities. All the pages on our website will meet W3C WAI’s Web Content Accessibility Guidelines 2.0, Level AA conformance. Report any issues to [email protected].

Do we want to change

[email protected]

to

[email protected]

or such?

The change made yesterday introduced bad HTML to the Accessibility Intro page. As I went lengths to clean up bad HTML, that was present on most of the old pages, please provide proper HTML5.

https://validator.w3.org/nu/?doc=http%3A%2F%2Fw3c.github.io%2Fwai-website%2Ffundamentals%2Faccessibility-intro%2F

• Using acronym
• having a shape="rect" attribute on a elements

Hi,

I used my old PC to check the site and few components look very distorted in IE 11+ Windows 7 combination. Chrome looks fine. Attached are the screenshots.

W3C logo should go to w3.org

"Web Accessibility Initiative WAI" should go to w3.org/wai/