w3c / unitas Goto Github PK

“Since Bootstrap doesn't know how much space the content in your navbar needs, you might run into issues with content wrapping into a second row”

— Overflowing content

Currently we're extra cautious taking space for the title on the navbar, to avoid the 2nd row issue. Even so, I think it may happen for certain combinations of title length, screen width and font size :(

On the other hand, restricting the width of the title too much causes ellipses to appear too early, and truncates titles too much.

Come up with some clever solution for this. I suspect it'll need some JS measuring on the fly to optimise space.

For usability (especially on small screens). Using media queries, succinct lists of items like /?a=all should split in multiple columns when reasonable.

The main content area of each page should be represented by the <main> element. Currently a <div> element is used, but this has no semantic meaning from an accessibility point of view.

When the <main> element is used, screen readers will indicate where the main content area of the page starts/stops. It also provides a hook that screen readers can use as a navigational hook to help people move efficiently to the main content of the page.

The "Details" section of each page should be represented using the <footer> element. Currently it is a <div> element, which has no semantic meaning from an accessibility point of view.

When the <footer> element is used, screen readers will identify it and indicate the point where the footer content starts/ends. It also provides a hook that screen readers can use as a navigation mechanism.

See
https://davidwalsh.name/javascript-debounce-function
or
https://css-tricks.com/debouncing-throttling-explained-examples/

I was talking with Virginie about this project and she would like to the ability to create a customized view of groups to follow and to be able to share that view (URI).

If you are interested in following a collection of groups that neither you nor your employer belong to, there isn't a convenient way to do so.

Pages corresponding to the most obscure types of items (charters, participations, affiliations) have a cryptic title (URIs or timestamps).

Work out some logic to give them a more representative title.

So that every item with an {ID,hash,URL} is rendered as a hyperlink pointing to the corresponding dynamic page for that item.

We're displaying names of fields and keys as they come from the API, eg teamcontacts instead of Team Contacts, or participation-as-public-ie-allowed instead of Public IE is allowed to participate (or something like that).

Fix.

…a calendar or timeline with relevant periods and milestones associated to the entity (more relevant for groups and specs, I think):

• Group charters.
• Dates when different versions of the same spec are published.
• Deadlines of calls for {reviews, participation, implementations, exclusions}.
• F2F meetings of a group.

(At least this is my understanding.)

Apparently a suggestion made during the AC in March 2016.

…or wait for Safari to catch up :¬P

h/t @tguild

Revert #57 when Safari starts behaving.

Unless there is a need to call it out visually, the <h2> at the start of the details section is not needed. If the <footer> element is used instead of the <div> (per issue #47), this will provide sufficient accessibility information for screen reader users.

Note: It can also be argued that the "Details" skip link at the top of each page is redundant. The <footer> element will provide a navigational hook for screen reader users, and all other keyboard users can use standard browser commands for moving focus to the bottom of the page.

…and add support for functions instead: /functions.

Now that we're using Bootstrap for responsive layout and components, there are more ARIA attributes and a11y tips that we should review.

Refer to getbootstrap.com/docs/4.0/getting-started/accessibility; review in particular navbars and modals.

Many should be sorted alphabetically (names of users, names of specs, names of companies, etc), while others are more tricky (eg, versions of specs and charters should be sorted by date).

eg, /?g=all should display the total no. of groups shown.

Suggest that "Members" should list member organizations and Participants (not Participations) should list individuals. Suggest that both lists should be alphabetized or sortable.

eg, in /?g=all, the field description of each group should be shown to the user somehow. Perhaps on a separate panel when the user hovers over each row.

Try to minimise the number of requests to the API extracting more data with every call.

It looks simple and ugly now. Line height is too tall. Space is wasted on the right-hand side as most fields have very short keys and values.

For users, the portrait should be positioned better.

Suggested:

• List of all domains (rather internal to W3C organisation; public but not really relevant/useful for the public).
• Participations (maybe integrate it inside affiliations, or users?).

Content coming from the API should be a progressive enhancements on pages.
Come up with a better layout that shows those “extension areas” if the UA is running JS, and that is in itself a complete, useful page if there's no JS or if the connection if flaky.

The first <h2> on some pages contains two pieces of information: the "about" text and the "permalink" anchor. In some screen readers, this causes the heading to be broken down into its component parts.

<h2 class="col-xs-12">About <a href="#about" class="permalink">⚓</a></h2>

Suggest including "About" inside the anchor:

<h2 class="col-xs-12"><a href="#about" class="permalink">About ⚓</a></h2>

It would also be a good idea to hide the anchor symbol from screen readers. Screen readers will identify the link based on the <a>, making the anchor symbol a largely visual reference:

<h2 class="col-xs-12"><a href="#about" class="permalink">About <span aria-hidden="true">⚓</span></a></h2>

Note: aria-hidden should not be used to hide the anchor symbol, if the symbol is the only content of the link.

In the "Participants" section on a WG page, it would be helpful if the list could be broken down into member organisations, invited experts, and W3C staff. Perhaps using a <dl> or sub-headings?

When scrolling to fragment IDs, those move right under the header overlay and aren't visible.

Apply the CSS trick

margin-top:  - var(--header-height);
padding-top: calc( var(--header-height) + var(--desired-padding) );

to offset the header height.

Either a list of blogs somehow associated to the group or to its users, or an integrated feed of all those blogs.

Possibly using Bootstrap.

eg, https://w3c.github.io/Unitas/entity.html?x=1913.

Suggest removing the title attribute from links.

Using the title attribute on links causes problems for screen magnifier users, and is unsupported on mobile/touch. For example:

<li class="list-group-item"><a title="Accessibility in India Community Group" href="?g=61068">Accessibility in India Community Group</a></li>

• Linkable: change URL to reflect current view.
• History-friendly: push and pop states to/from browsing history.

Advantages (recycled from an analogous PR on project mailing-list-archives):

• Faster to load: just one HTTP request; no need to fetch associated favicon, JS and CSS resources, etc. (Yes, all those assets should ideally be cached, but we know often it's not the case).
• Faster to render: saves many steps on the rendering pipeline, the same DOM stays, only the contents of a few elements are changed.
• More responsive: the user doesn't stare at a blank page while loading, or to a new DOM being built; they can continue scrolling the page, reading around the message, or interacting with it in other ways while the new message is being fetched.
• Scroll position on the page is kept.

Where <li> elements are used, they need to be children of a <ul> element. For example on the "All groups" page (and others that share the same template pattern):

<div class="panel-body">
<li class="list-group-item"><a title="Accessibility in India Community Group" href="?g=61068">Accessibility in India Community Group</a></li>
...
</div>

Without the parent <ul> element, the browser does not expose the <li> elements as being part of a collection. This means that people who use a screen reader (because they cannot see the page) are unaware of how big the collection is - useful metadata that is otherwise obvious at a glance.

There are at least 9 types of entities one can visit in Unitas.

Make it clear what are the relations among them with a directed graph with one node per type of entity. It'll help developers of the API and of Unitas in the long run, and serve as a reference when we change the architectures of pages or of navigation.

cf w3c/w3c-api#70 (comment)

Because sections are generated dynamically, sometimes Scrollspy doesn't react to scroll.

Make sure we refresh it once all sections have been populated.

Yandex Browser 16.3 on Mac OS

If I open e.g. a group page, scroll down, then scroll back to the top, I can no longer read the header. (I'm not sure if this is related to #37 or not), but it's a bug…

Apparently a suggestion made during the AC in March 2016.

#10 is not solved completely.

Margins between sections are too wide. The trick of reducing it selectively only for the :target'ed element is weird, and the trick is apparent when you scroll past that item, or if several elements are visible on screen and you toggle selection between them.

Fix.

This is where this might fit within the current prototype.

eg, ?d=all to list all domains, instead of presenting information about one in particular.

This, together with #2, would allow us to use entity.html as the ultimate crawler or browser for the API (for humans): one could set off from entity.html?d=all and make his way all through the hierarchy down to virtually any other item in the graph.

Probably because sections and widgets are being added to the DOM dynamically, when there's an #anchor in the URL, often/always that element is not scrolled into view as it should.

Scroll by hand once body is .loaded.

Usual IRC channel(s), mailing list(s)…

See:

• SitePoint: “How to Use SVG Image Sprites”.
• SitePoint: “A Working SVG Workflow for Accessible Icons”.
• Sara Soueidan: “Structuring, Grouping, and Referencing in SVG — The <g>, <use>, <defs> and <symbol> Elements”.

From the moment the page loads to when it's “complete” (all data is shown), there should be a clear indication that something is happening.
Spinner, progress bar, “please wait” message, etc.

Apparently a suggestion made during the AC in March 2016.

The number of different types of “entities” in the W3C domain is growing.
It would help navigation to identify them clearly, in an intuitive way.

We did something like this for one of the very early prototypes for an API consumer:

I still like the idea (minus the font icons, of course).

So that it stays usable even afer scrolling.

A page visit should not trigger a bunch of API requests every single time the same user visits it on the same client.

Some wild ideas:

• Client-side:
  • Web storage.
  • Web SQL DB.
  • Indexed DB.
  • Service workers.
  • Application cache.
  • Cookies.
• Server-side:
  • Configure W3C's servers to cache common API requests. The requests for the most common entities (probably: groups and specs) can be easily cached if we ignore the API key and assume there's not pagination, etc. I suspect that makes up a big chunk of the total number of requests the API will receive.